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

Discussion in 'C++' started by deepadivakaruni@gmail.com, Jan 25, 2014.

  1. Guest

    i think so c++ is more complicated when compared to c.And also the many keywords are used to perform only one application.
    , Jan 25, 2014
    #1
    1. Advertising

  2. Jorgen Grahn Guest

    On Sat, 2014-01-25, wrote:
    > i think so c++ is more complicated when compared to c.


    Like Juha (?) likes to say: more complicated language, less
    complicated application-specific code. If the complication hits me
    over and over and over again, I prefer if the language deals with it.
    Implementing linked lists gets boring when you've done it a few times.

    > And also the
    > many keywords are used to perform only one application.


    I don't understand that sentence. Also, to which posting are you
    responding? Is it some posting from the 1990s, resurrected by the
    broken Google interface?

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 25, 2014
    #2
    1. Advertising

  3. Öö Tiib Guest

    On Saturday, 25 January 2014 19:05:05 UTC+2, Jorgen Grahn wrote:
    > On Sat, 2014-01-25, wrote:
    > > And also the
    > > many keywords are used to perform only one application.

    >
    > I don't understand that sentence.


    Me neither.

    > Also, to which posting are you
    > responding? Is it some posting from the 1990s, resurrected by the
    > broken Google interface?


    deepadivakaruni is responding to 11 years old thread.
    Öö Tiib, Jan 25, 2014
    #3
  4. On 25.01.2014 17:48, wrote:
    > i think so c++ is more complicated when compared to c.


    Yes, but that is not a disadvantage of the language for embedded systems.


    > And also the many keywords are used to perform only one application.


    Well, ditto.

    * * *

    Thread subject line:
    "What is the disadvantage with C++ in Embedded systems?"

    Please state your question in the article, not only in the subject line.

    From the statements in the article one would think you were asking
    something unspecified about the language complexity.

    * * *

    A main disadvantage of C++ for embedded systems, and for OS drivers
    etc., compared to C, is that full C++ requires much RUNTIME SUPPORT that
    C doesn't require, in particular for dynamic initialization of statics,
    exception handling and RTTI like dynamic_cast.

    There was once an initiative to use a subset of C++ called "EC++", see
    <url: http://en.wikipedia.org/wiki/Embedded_C%2B%2B>, but it went too
    far, was too impractical, and has been effectively dead since 2002.


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jan 29, 2014
    #4
  5. On 29.01.2014 17:31, Robert Wessel wrote:
    > On Wed, 29 Jan 2014 15:01:04 +0100, "Alf P. Steinbach"
    > <> wrote:
    >
    >> On 25.01.2014 17:48, wrote:
    >>> i think so c++ is more complicated when compared to c.

    >>
    >> Yes, but that is not a disadvantage of the language for embedded systems.
    >>
    >>
    >>> And also the many keywords are used to perform only one application.

    >>
    >> Well, ditto.
    >>
    >> * * *
    >>
    >> Thread subject line:
    >> "What is the disadvantage with C++ in Embedded systems?"
    >>
    >> Please state your question in the article, not only in the subject line.
    >>
    >> From the statements in the article one would think you were asking
    >> something unspecified about the language complexity.
    >>
    >> * * *
    >>
    >> A main disadvantage of C++ for embedded systems, and for OS drivers
    >> etc., compared to C, is that full C++ requires much RUNTIME SUPPORT that
    >> C doesn't require, in particular for dynamic initialization of statics,
    >> exception handling and RTTI like dynamic_cast.

    >
    >
    > Well, it requires *some* runtime support for those things. "Much" is
    > arguable.
    >
    > For example, RTTI usually requires only a pointer in each vtable (per
    > vtable, so per class, not per instance) to a (short) block of type
    > information (typical overhead is under 50 bytes per class). The
    > routines needed to deal with that are pretty short too (depending on
    > the use, typeid can be very short - a lookup in the vtable, and
    > dynamic_cast requires a bit of a walk of the class hierarchy graph).
    > Other than the per-class memory overhead, RTTI doesn't impose any
    > execution time costs, unless you actually do a typeid or dynamic_cast.


    I wasn't talking about size or time costs, but rather, the need for that
    information to exist and be initialized.


    > Exceptions usually require a few extra instructions at routine/block
    > entry and exit, a few bytes of stack space for each of those, and a
    > small amount of code at the throw and catch (some (small) common
    > chunks of which sometimes end up the library).


    Exceptions require far more than you list (e.g. to support
    std::exception_ptr), but ditto: it's not the space or time overhead
    that's at issue.



    > Dynamic initialization of statics (and ctors on statics), require the
    > compilation of a list of pointers to each such static, and then
    > runtime support to step through that list, calling each ctor in turn
    > (IOW, several lines of code), and, of course the actual code for the
    > initialization of each object.


    Ditto: while space and time may be relevant on some devices, they're not
    showstoppers, but the assumption of control that's inherent in C++'s
    requirements of runtime support, can be.

    At one time the issues that I pointed at meant that these features were
    simply not available for some environments, As I recall, in particular
    one mobile phone OS didn't support dynamic initialization of statics,
    exceptions or RTTI. One had to make do with a slightly lobotomized
    ARM-style C++.

    Things have changed and are changing, especially for CUDA programming
    (which I need to delve into!), but the issues are there still.


    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jan 29, 2014
    #5
  6. Robert Wessel schreef op 29-Jan-14 5:31 PM:
    > Exceptions usually require a few extra instructions at routine/block
    > entry and exit, a few bytes of stack space for each of those, and a
    > small amount of code at the throw and catch (some (small) common
    > chunks of which sometimes end up the library).
    >
    > So those have some overhead, but it's not like they're going to drag
    > in hundreds of KB of runtime library or triple the size of the object
    > code, and what embedded compiler doesn't have at least something in
    > the CRT anyway?


    More a library implementation issue than a language issue, but when I
    build my Cortex M0 application with exception handling some exception
    handler (the one around main?) is linked along and the minimum
    application size is ~ 500 Kb. And my poor chip has only 8Kb.

    Wouter
    Wouter van Ooijen, Jan 29, 2014
    #6
  7. Jorgen Grahn Guest

    On Wed, 2014-01-29, Wouter van Ooijen wrote:
    > Robert Wessel schreef op 29-Jan-14 5:31 PM:
    >> Exceptions usually require a few extra instructions at routine/block
    >> entry and exit, a few bytes of stack space for each of those, and a
    >> small amount of code at the throw and catch (some (small) common
    >> chunks of which sometimes end up the library).
    >>
    >> So those have some overhead, but it's not like they're going to drag
    >> in hundreds of KB of runtime library or triple the size of the object
    >> code, and what embedded compiler doesn't have at least something in
    >> the CRT anyway?

    >
    > More a library implementation issue than a language issue, but when I
    > build my Cortex M0 application with exception handling some exception
    > handler (the one around main?) is linked along and the minimum
    > application size is ~ 500 Kb. And my poor chip has only 8Kb.


    /Definitely/ not a language issue! Half a megabyte is absurdly much.
    Pulling in iostreams /and/ stdio might /possibly/ explain it.
    What does the symbol table say?

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 29, 2014
    #7
  8. Jorgen Grahn schreef op 29-Jan-14 7:41 PM:
    > /Definitely/ not a language issue! Half a megabyte is absurdly much.
    > Pulling in iostreams /and/ stdio might /possibly/ explain it.
    > What does the symbol table say?


    iostreams indeed.

    Wouter
    Wouter van Ooijen, Jan 29, 2014
    #8
    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:
    360
    PenguinPig
    Jun 24, 2006
  4. Dipankar
    Replies:
    17
    Views:
    10,682
    Arne Vajhøj
    Aug 1, 2009
  5. Rainer Grimm
    Replies:
    9
    Views:
    104
    David Brown
    Jan 29, 2014
Loading...

Share This Page