Re: What is the disadvantage with C++ in Embedded systems?

Discussion in 'C++' started by Rainer Grimm, Jan 27, 2014.

  1. Rainer Grimm

    Rainer Grimm Guest

    > > What is the disadvantage with C++ in Embedded systems?.
    I'm new in the embedded world. So I was astonished and irritated
    how dominant C is in the area. Because of that impression I gave
    a presentation in order to show, what C++11 can offer you in embedded world.
    Here is my presentation:
    http://meetingcpp.com/tl_files/2013/talks/EmbeddedC 11 - RainerGrimm.pdf
    Additonal to that there is a excellent paper describing in very detail the
    performance issues of C++.
    http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf
    I'm sure that the embedded world is one of the keys domains of C++.
    Rainer Grimm, Jan 27, 2014
    #1
    1. Advertising

  2. Richard Damon schreef op 28-Jan-14 3:00 PM:
    > I see a few big reasons that C++ is relatively uncommon in the embedded
    > world.
    >
    > 1) Many of the processors used in the embedded world tend to be "small
    > market" in terms of demand for tools, and it would seem to be
    > significantly simpler to make a C compiler for a system then a C++ one.


    Can't argue with that (if there is no C++ compiler for a chip you
    obviously can't use C++ on it), but there are GCC (including G++)
    compilers for AVR and ARM/Cortex, which together are a significant part
    of the small-chips market.

    > 2) Embedded systems are much more sensitive to efficiency concerns.
    > While C++ has done a good job of keeping to the "don't pay for what you
    > don't use", there are a few areas where this doesn't hold (or at least
    > the perception is that it doesn't). One big area for this is exceptions.
    > When using C++, you really can't just ignore exceptions


    At least for GCC you can: put -fno-exceptions on the command line and
    forget about them.

    > 3) C++ has the most to offer for BIG systems, where the encapsulation
    > can help manage complexity. Most embedded systems, almost by definition,
    > don't get that complex (because there isn't enough machine to put that
    > much complexity into). This reduces the demand for it, so coupled with
    > point 1, resources don't get allocated to it.


    Which is a pity, because small projects can benefit a lot from code
    reuse, and C++ offers mechanisms (templates, static class attributes)
    that have zero overhead.

    > 4) Perception-wise, it is easier for a mediocre C++ program to make a
    > big mess than a C programmer. Misusing features like templates and
    > inheritance can seriously bloat a program. While this isn't really the
    > language's fault, some managers can feel that they have been burnt by
    > this too many times, so want to avoid it. (of coarse here the real
    > answer is to learn not to make that sort of mistake, bad programmers can
    > make a mess in any language).


    (amen to the last sentence)

    > C++ is NOT going to buy
    > that much of a gain in the initial system. (There may be some longer
    > term justifications, but that is often harder to make, those savings can
    > be from a totally different budget).


    One day I hope to prove that C++ (when used appropriately) has A LOT to
    offer for programming small systems (micro-controllers).

    Wouter
    Wouter van Ooijen, Jan 28, 2014
    #2
    1. Advertising

  3. Scott Lurndal schreef op 28-Jan-14 5:18 PM:
    > In fact, I've written several "embedded" applications (two operating systems
    > and two hypervisors, for very large-scale systems) in C++. Avoiding exceptions
    > was mandatory (given the lack of a runtime), and templates were discouraged
    > (to reduce cache footprint for the OS/Hypervisor).


    My (so far small-scale) experience with templates is that you can use
    them to give the compiler the chance to do inlining followed by other
    optimzations, thus reducing the code size.

    Of course, this must be used with care: code that does not depend on the
    template arguments and does not benefit from said optimizations
    should be outside the template.

    > GCCFLAGS += -nostdlib # Don't use /lib


    I use the same. IMO it nicely sumarizes the situation of small-system
    programmers with respect to the overall C++ community: the compiler is
    usesfull, but the libraries are almost useless.

    > There is no rule that states one must use _all_ features of C++ in every
    > single C++ program, notwithstanding some dogmatic contributors to this
    > newsgroup.


    Total agreement here. And bafflement why anyone should think otherwise.
    Every language feature has its place (for some it is down there with the
    suplhur and fire). Use what is beneficial, ignore the rest. And if you
    can, enforce this in your toolchain! Personally I hate global objects
    with run-time initialization (if anyone doesn't understand why start
    googling NOW), so in the linkerscript I allocate a 0-size region called
    'stupid_fool_you_used_a_global_object_with_runtime_initialization" for
    the .init and .preinit_array sections.

    Wouter
    Wouter van Ooijen, Jan 28, 2014
    #3
  4. Rainer Grimm

    David Brown Guest

    On 28/01/14 15:00, Richard Damon wrote:
    > On 1/27/14, 1:53 AM, Rainer Grimm wrote:
    >>>> What is the disadvantage with C++ in Embedded systems?.

    >> I'm new in the embedded world. So I was astonished and irritated
    >> how dominant C is in the area. Because of that impression I gave
    >> a presentation in order to show, what C++11 can offer you in embedded world.
    >> Here is my presentation:
    >> http://meetingcpp.com/tl_files/2013/talks/EmbeddedC 11 - RainerGrimm.pdf
    >> Additonal to that there is a excellent paper describing in very detail the
    >> performance issues of C++.
    >> http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf
    >> I'm sure that the embedded world is one of the keys domains of C++.
    >>

    >
    > I see a few big reasons that C++ is relatively uncommon in the embedded
    > world.
    >
    > 1) Many of the processors used in the embedded world tend to be "small
    > market" in terms of demand for tools, and it would seem to be
    > significantly simpler to make a C compiler for a system then a C++ one.
    >


    The small ones for which a C++ compiler would be much harder, such as
    the 8051, are very much on the decline. All the major C compiler
    vendors support C++ (GHS, CodeWarrior, Mentor, etc.) for all but the
    most brain-dead microcontrollers - and of course, gcc is available for
    dozens of architectures and is, I believe, by far the most common
    embedded compiler. (For some architectures, gcc C++ is limited from
    lack of library support, but that mostly affects exceptions and RTTI.)

    However, many commercial vendors still view C++ as a "premium" choice,
    and price accordingly - making it a major investment for small users.
    For example, Code Warrior is free for a limited (but perfectly usable)
    code size as long as you program in C - if you want C++, you need the
    full version at $5000. This is despite the fact the compiler you use
    for some targets is actually gcc - the debugger, libraries, wizards,
    etc., are all C only for the free and low-cost versions.

    Prices like that are okay for big projects, but the added investment is
    often hard to justify.

    > 2) Embedded systems are much more sensitive to efficiency concerns.
    > While C++ has done a good job of keeping to the "don't pay for what you
    > don't use", there are a few areas where this doesn't hold (or at least
    > the perception is that it doesn't). One big area for this is exceptions.
    > When using C++, you really can't just ignore exceptions


    Yes you can - all embedded toolchains will have an equivalent of the
    "-fno-exceptions" switch, along with a "-fno-rtti". Of course, that
    means you can't use exception-heavy PC code directly on your embedded
    system, but that is usually the case anyway. In particular, in embedded
    code you normally want to minimise dynamic memory, while in PC code you
    typically consider it to be "free".

    > (though there is
    > a variant "Embedded C++" which removes them).


    "Embedded C++" was a piece of crap from the day it was conceived - some
    of the compromises chosen are daft. Dropping exceptions, RTTI, and
    multiple inheritance was reasonable enough - dropping templates was
    silly, and dropping namespaces gains absolutely nothing.

    > Early versions of
    > exception had execution costs in all cases which was bad for embedded,
    > more recently techniques have been developed where this has changed to a
    > space cost (for tables to define unwinding), and time on the exception
    > path. The non-obvious costs on these paths can be a barrier for C++, as
    > sometimes in the embedded world there are performance requirements even
    > on the error paths.
    >


    Yes - exceptions can make it hard to see all possible execution paths.
    For embedded systems, you can't just crash with a helpful error message
    if you fail to catch an exception.

    Also, exceptions can cause limitations with optimisers - and embedded
    systems often have to make greater use of less processing resources than
    in the PC world.

    > 3) C++ has the most to offer for BIG systems, where the encapsulation
    > can help manage complexity. Most embedded systems, almost by definition,
    > don't get that complex (because there isn't enough machine to put that
    > much complexity into). This reduces the demand for it, so coupled with
    > point 1, resources don't get allocated to it.
    >
    > 4) Perception-wise, it is easier for a mediocre C++ program to make a
    > big mess than a C programmer. Misusing features like templates and
    > inheritance can seriously bloat a program. While this isn't really the
    > language's fault, some managers can feel that they have been burnt by
    > this too many times, so want to avoid it. (of coarse here the real
    > answer is to learn not to make that sort of mistake, bad programmers can
    > make a mess in any language).
    >
    > None of these says that you CAN'T use C++ for an embedded project, but
    > the provide dis-incentives for it. As a common example, for many of the
    > chips I have used, the chip vendor provides a version of a C development
    > platform for free with some small limitations, and a full C system for
    > not much money (less than a day pay). For the reasons above, the haven't
    > made the effort to provide a C++ solution (there hasn't been enough call
    > for it to make it worth it). There is perhaps a 3rd party vendor with a
    > C++ system available, but its cost is more like a month's pay. IT can be
    > hard to make the economic justification that the C++ system is worth it
    > at the beginning of the development cycle, especially if the estimate
    > for the program time is only a very few months, C++ is NOT going to buy
    > that much of a gain in the initial system. (There may be some longer
    > term justifications, but that is often harder to make, those savings can
    > be from a totally different budget).
    >


    Agreed.
    David Brown, Jan 28, 2014
    #4
  5. Rainer Grimm

    Jorgen Grahn Guest

    On Tue, 2014-01-28, David Brown wrote:
    ....
    > The small ones for which a C++ compiler would be much harder, such as
    > the 8051, are very much on the decline. All the major C compiler
    > vendors support C++ (GHS, CodeWarrior, Mentor, etc.) for all but the
    > most brain-dead microcontrollers - and of course, gcc is available for

    ....

    > ... In particular, in embedded
    > code you normally want to minimise dynamic memory, while in PC code you
    > typically consider it to be "free".


    I think it has been said here recently, but anyway: lots of embedded
    systems are no longer small. The ones I've worked on for the last
    decade or so have run some Unix, frequently have lots of fast CPUs,
    and more memory than we'll ever find a use for.

    (Of course, I acknowledge the existence of the other kinds too, and
    that they ship more units.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 28, 2014
    #5
  6. Rainer Grimm

    Jorgen Grahn Guest

    On Tue, 2014-01-28, Richard Damon wrote:
    > On 1/27/14, 1:53 AM, Rainer Grimm wrote:
    >>>> What is the disadvantage with C++ in Embedded systems?.

    >> I'm new in the embedded world. So I was astonished and irritated
    >> how dominant C is in the area.

    ....
    > I see a few big reasons that C++ is relatively uncommon in the embedded
    > world.


    [snip things I don't agree with]

    > 4) Perception-wise, it is easier for a mediocre C++ program to make a
    > big mess than a C programmer. Misusing features like templates and
    > inheritance can seriously bloat a program. While this isn't really the
    > language's fault, some managers can feel that they have been burnt by
    > this too many times, so want to avoid it.


    My pet theory is that a lot of the problems C++ has (embedded or not)
    stems from failed and almost-failed projects in the 1990s. "Let's
    rewrite this system in C++, it's the next big thing!", followed by
    - Inadequate training
    - Too much focus on orthodox Object-Oriented Design a la Smalltalk
    - Pre-standard language, with no standard library, no templates ...

    People (not just managers) remember such things. Sometimes, they are
    still sitting there today maintaining them ...

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 28, 2014
    #6
  7. Rainer Grimm

    Guest

    > Templates should be considered as zero overhead because you only get the
    > code you asked for. The "problem" with templates is it can be too easy
    > to ask for lots of code when you don't realize it.


    There is one important feature that templates have and that is missing in "pure C" - the ability to pass constants down the instantiated component. Constants are pretty cool - they can be used, for example, to define buffer sizes.

    Now imagine I have a component that internally uses some buffer. This buffer needs a size and in order to avoid dynamic memory management (we are talking embedded, right?) this buffer needs to be sized statically. In C the only reasonable and widely practiced way is via preprocessor macros:

    #define FOOBAR_BUFFER_SIZE 1024

    But then it is not possible (or it's impractical) to instantiate two foobars with different buffer sizes in a single program.

    Templates provide a clean way to do that:

    FooBar<1024> smallFB;
    FooBar<2048> bigFB;

    without introducing any unreasonable overhead.

    I would *love* to have this possibility in embedded projects and this is one important reason I would consider C++ there.

    --
    Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
    , Jan 29, 2014
    #7
  8. schreef op 29-Jan-14 10:19 AM:
    > #define FOOBAR_BUFFER_SIZE 1024
    >
    > But then it is not possible (or it's impractical) to instantiate two foobars with different buffer sizes in a single program.
    >
    > Templates provide a clean way to do that:
    >
    > FooBar<1024> smallFB;
    > FooBar<2048> bigFB;
    >
    > without introducing any unreasonable overhead.
    >
    > I would *love* to have this possibility in embedded projects and this is one important reason I would consider C++ there.
    >


    There are ways to do that in C, one would be putting the all of the
    ringbuffer declaration in a macro. (That has of course other reprecussions.)

    As simple use of this feature is a fixed-maximum-size string:

    class string;

    template<>
    class string<> {
    public:

    char * body;
    unsigned int _maximum, _size;

    string( char *body, unsigned int maximum ):
    body( body ), _maximum( maximum ), _size( 0 ){}

    public:

    ::: all string operators :::

    };

    template< unsigned int n >
    class string : public string<> {
    char body[ n ];
    public:

    string() : string<>( body, n ){}

    ::: a few operators that must be string<n> specific
    };

    The strings of different size are all compatible with the base class
    string<> and can be used in combination, yet they all have their
    individual maximum size.

    Wouter
    Wouter van Ooijen, Jan 29, 2014
    #8
  9. Rainer Grimm

    David Brown Guest

    On 29/01/14 10:19, wrote:
    >> Templates should be considered as zero overhead because you only
    >> get the code you asked for. The "problem" with templates is it can
    >> be too easy to ask for lots of code when you don't realize it.

    >
    > There is one important feature that templates have and that is
    > missing in "pure C" - the ability to pass constants down the
    > instantiated component. Constants are pretty cool - they can be used,
    > for example, to define buffer sizes.
    >
    > Now imagine I have a component that internally uses some buffer. This
    > buffer needs a size and in order to avoid dynamic memory management
    > (we are talking embedded, right?) this buffer needs to be sized
    > statically. In C the only reasonable and widely practiced way is via
    > preprocessor macros:
    >
    > #define FOOBAR_BUFFER_SIZE 1024
    >
    > But then it is not possible (or it's impractical) to instantiate two
    > foobars with different buffer sizes in a single program.
    >
    > Templates provide a clean way to do that:
    >
    > FooBar<1024> smallFB; FooBar<2048> bigFB;
    >
    > without introducing any unreasonable overhead.
    >
    > I would *love* to have this possibility in embedded projects and this
    > is one important reason I would consider C++ there.
    >


    There are many cases where C requires macros (often complicated ones) to
    get efficient code code. Often with low-level embedded code you are
    dealing with memory-mapped peripherals, and if you have several
    identical peripherals it can be difficult to get efficient code (i.e.,
    without extra layers of indirection caused by pointer-to-peripheral
    function arguments) - you end up with duplicate source code, ugly
    macros, etc. Templates on integers can let you write a neat template
    class that gives you the most direct possible access to such peripherals
    while still retaining a nice function or class interface.
    David Brown, Jan 29, 2014
    #9
  10. Rainer Grimm

    David Brown Guest

    On 28/01/14 22:01, Jorgen Grahn wrote:
    > On Tue, 2014-01-28, David Brown wrote:
    > ...
    >> The small ones for which a C++ compiler would be much harder, such as
    >> the 8051, are very much on the decline. All the major C compiler
    >> vendors support C++ (GHS, CodeWarrior, Mentor, etc.) for all but the
    >> most brain-dead microcontrollers - and of course, gcc is available for

    > ...
    >
    >> ... In particular, in embedded
    >> code you normally want to minimise dynamic memory, while in PC code you
    >> typically consider it to be "free".

    >
    > I think it has been said here recently, but anyway: lots of embedded
    > systems are no longer small. The ones I've worked on for the last
    > decade or so have run some Unix, frequently have lots of fast CPUs,
    > and more memory than we'll ever find a use for.
    >
    > (Of course, I acknowledge the existence of the other kinds too, and
    > that they ship more units.)
    >
    > /Jorgen
    >


    That is certainly true. I often talk about "small" embedded systems, as
    distinct from "embedded linux" and "pc without a keyboard" embedded
    systems. "Resource constrained" is another useful term, but there is no
    clear way to give exact classifications here.
    David Brown, Jan 29, 2014
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joe
    Replies:
    3
    Views:
    4,427
    Sudsy
    Dec 5, 2003
  2. dorayme
    Replies:
    11
    Views:
    1,070
    Neredbojias
    Sep 21, 2005
  3. PenguinPig

    Disadvantage of Resource

    PenguinPig, Jun 24, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    359
    PenguinPig
    Jun 24, 2006
  4. Dipankar
    Replies:
    17
    Views:
    10,682
    Arne Vajhøj
    Aug 1, 2009
  5. Replies:
    7
    Views:
    104
    Wouter van Ooijen
    Jan 29, 2014
Loading...

Share This Page