Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: What is the disadvantage with C++ in Embedded systems?

Reply
Thread Tools

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

 
 
deepadivakaruni@gmail.com
Guest
Posts: n/a
 
      01-25-2014
i think so c++ is more complicated when compared to c.And also the many keywords are used to perform only one application.
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-25-2014
On Sat, 2014-01-25, http://www.velocityreviews.com/forums/(E-Mail Removed) 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 .
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      01-25-2014
On Saturday, 25 January 2014 19:05:05 UTC+2, Jorgen Grahn wrote:
> On Sat, 2014-01-25, (E-Mail Removed) 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.
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-29-2014
On 25.01.2014 17:48, (E-Mail Removed) 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

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-29-2014
On 29.01.2014 17:31, Robert Wessel wrote:
> On Wed, 29 Jan 2014 15:01:04 +0100, "Alf P. Steinbach"
> <(E-Mail Removed)> wrote:
>
>> On 25.01.2014 17:48, (E-Mail Removed) 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

 
Reply With Quote
 
Wouter van Ooijen
Guest
Posts: n/a
 
      01-29-2014
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

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-29-2014
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 .
 
Reply With Quote
 
Wouter van Ooijen
Guest
Posts: n/a
 
      01-29-2014
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What was the project that made you feel skilled in Python? Ned Batchelder Python 2 05-20-2013 03:16 PM
oh perlbal you!!! you got what i need....but you dotn work with 5 16 johannes falcone Perl Misc 6 05-16-2013 08:11 PM
Problem with the Java Access Bridge and the screenreader JAWS Markus Lemcke Java 3 05-07-2013 05:27 PM
What is the reason for defining classes within classes in Python? vasudevram Python 6 04-24-2013 01:29 PM
what is the advantage of using maven for java standalone app mcheung63@gmail.com Java 13 04-16-2013 01:42 AM



Advertisments