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

[vasanta]

What is the disadvantage with C++ in Embedded systems?. Why C is
preferred than C++ in embedded systems?. Thanks in advance for help,
appreciated.

[Mike Wahler]

vasanta <tvn...@yahoo.com> wrote in message
news:5d593b38.03022...@posting.google.com...

> What is the disadvantage with C++ in Embedded systems?.

Lack of compilers.

Those that are available are typically limited in features.

More embedded programmers know C than C++.

> Why C is
> preferred than C++ in embedded systems?.

I think that question contains a generalization which
makes any answer moot.

-Mike

[David White]

vasanta <tvn...@yahoo.com> wrote in message
news:5d593b38.03022...@posting.google.com...

> What is the disadvantage with C++ in Embedded systems?.

I don't know of any. Any disadvantages are more likely the result of the
programming techniques used than the language itself. For instance, memory
allocation is easier in C++, so programmers might be more tempted to put
'new' in places where they would think twice about 'malloc' in C. Dynamic
memory allocation in embedded systems, except at startup, is usually asking
for trouble, because it is hard or impossible to prove that fragmentation
won't result in a memory allocation failure after months of continuous
running. Also, any memory leaks are fatal. Remember that C++ is largely a
superset of C, so you can always choose which C++-only features to use or
ignore, or you can ignore them all, but I suppose you should take into
account the relative likelihood of a given programmer to do something
dangerous in each language.

Another possibility is that the available compilers are not reliable enough.

>Why C is
> preferred than C++ in embedded systems?.

Maybe because of the availability or reliability of C++ compilers, or
possibly because of a misplaced perception that the language itself is not
suitable for embedded systems.

David

[E. Robert Tisdale]

vasanta wrote:

> What is the disadvantage with C++ in embedded systems?.

There are more good optimizing C compilers than C++ compilers
for embedded systems.

> Why C is preferred than C++ in embedded systems?.

Because more embedded systems programmers know C
better than they know C++.

This situation may change rapidly soon.

Take a look at
the Vector, Signal and Image Processing Library (VSIPL) home page:

http://www.vsipl.org/

Click on

High Performance Embedded Computing Software Initiative

It will take you to the HPEC-SI home page:

http://www.hpec-si.org/

There are ANSI/ISO C and C++ language bindings for the VSIPL API.
The libraries are targeted mainly for
embedded Digital Signal Processors (DSPs).

Of course, this topic has been discussed to death
in the comp.arch.embedded newsgroup.

[Thomas Matthews]

tvn...@yahoo.com (vasanta) wrote in message news:<5d593b38.03022...@posting.google.com>...

> What is the disadvantage with C++ in Embedded systems?. Why C is
> preferred than C++ in embedded systems?. Thanks in advance for help,
> appreciated.

The main reasons I've encountered is that most embedded software
programmers don't know C++.

In one project I worked on, we agreed that new code would be (or could
be) developed in C++. If any old code need to work with new code, the
new code must provide a C language interface.

A more important issue with embedded programming is encapsulation and
module / source re-use. I don't consider inheriting of parent code
to a child as re-use. I'm talking about _different_ projects sharing
source code. But that is one of my pet peeves.

-- Thomas Matthews

[steve H]

The main disadvantage of using C++ in embedded systems is the amount
of overhead required when using C++ as opposed to C. This may not be
too much of a problem when using a high speed desktop PC that has
loads of memory available but most embedded systems have limited
memory capability and cannot afford the luxury of using instructions
to access functions in classes or wherever. Consider the problem, of
an 8051 microcontroller operating at 12Mhz, that may require 12 clock
cycles to complete each instruction. The scope for using instructions
to make calls to functions within the program becomes limited and can
slow operations down. (speed of operation being something that is
normally a requirement of an embedded system). Object oriented
programming is fine and offers loads of advantages when speed of
operation and memory is not an issue. Aside from that, C++ is a
perfectly valid option in embedded programming.

[White Wolf]

"steve H" wrote:
> The main disadvantage of using C++ in embedded systems is the amount
> of overhead required when using C++ as opposed to C.

This is all bullbyproduct. C++ requires *no* overhead compared to C.
It would be nice if people would not spread urban legends here. If you
look at the definition of C++ you will see that *if* make the *same*
program in C and C++ there is *no cause* for which the C++ program
should be any slower. Of course, if you make a more robust (exceptions,
dynamic buffers etc) or a more dynamic or a more configurable program
you wiull pay for that. Usually less than doing it in C - if the change
is big enough.

[Sandeep]

Overhead of C++ over C is significant only when you are working with
8 bit and 16 bit micros. With any other processor there is no reason
to be still using C.

The problem is that some software developers mindsets do not follow the
Moore's law and many people prefer to program as if we are still
in the early 80s.

The following articles cover C and C++ performance:

http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm

http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance2.htm

Sandeep
--
http://www.EventHelix.com
EventStudio - Generate Sequence Diagrams in PDF

[deepadi...@gmail.com]

i think so c++ is more complicated when compared to c.And also the many keywords are used to perform only one application.

[Jorgen Grahn]

On Sat, 2014-01-25, deepadi...@gmail.com 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 .

[Öö Tiib]

On Saturday, 25 January 2014 19:05:05 UTC+2, Jorgen Grahn wrote:
> On Sat, 2014-01-25, deepadi...@gmail.com 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.

[Rainer Grimm]

> > 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%20-%20RainerGrimm.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++.

[W Karas]

Suppose you had a car with a lever that could switch it into 4-wheel drive. Your question is analogous to asking if you should remove the lever, so it would always run in 2-wheel drive.

A C99 program can be compiled with a C++ compiler with, at most, minor modifications. If there is any significant performance difference, that means the C++ compiler needs improving. It's not a consequence of differences in the languages.

If you use C++-specific features (not in C), there are performance implications. Just as there are performance implications to using 4-wheel drive instead of 2-wheel drive. Here is something I wrote that delves into that issue somewhat:

http://wkaras.webs.com/Cpp_overhead.html

A "managerial" argument that one hears is that, few programmers are careful enough to make good decision about when and how to use C++ features. I think in some niches that may be applicable. Thing is, dynamic allocation of resources is pretty common in code bases. So now you're looking for programmers who are thoughtful enough to do dynamic allocation WITHOUT all the C++ features for error-proofing dynamic allocation, yet not able or willing to use C++ effectively.

[Richard Damon]

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.

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 (though there is
a variant "Embedded C++" which removes them). 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.

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).

[Wouter van Ooijen]

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

[Scott Lurndal]

Wouter van Ooijen <wou...@voti.nl> writes:
>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.

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).

-fno-exceptions was used in all cases.

Here are the compiler flags we used for the hypervisor:

#
# The compiler can be instructed to use the %RBP register as a
# frame pointer. This reduces the available register pool by one and
# does increase the size of the dvmm by about 1%, but it produces complete
# and reliable stack tracebacks.
#GCCFLAGS+= -fomit-frame-pointer # Don't reserve RBP for frame info
GCCFLAGS += -fno-omit-frame-pointer # Reserve RBP for frame info

DEFINES = -DUSE_FRAMEPOINTER

#
# We're PIC because the monitor doesn't live in either the first
# 2GB (mcmodel=small) or the last 2GB (mcmodel=kernel). We could use
# mcmodel=large, but gcc 3.4 doesn't implement that yet.
#
GCCFLAGS += -fPIC # Position Independent Code
GCCFLAGS += -mno-red-zone # Don't use stack redzone
GCCFLAGS += -fno-strict-aliasing # Compiler can't assume no aliases
GCCFLAGS += -nostdlib # Don't use /lib
GCCFLAGS += -nostartfiles # Don't use crt0.o
GCCFLAGS += -Wall # Turn on all warning conditions
GCCFLAGS += -Werror # Make warnings fatal
GCCFLAGS += -g

OPTIMFLAGS = -mtune=opteron # Tune for the opteron processor
OPTIMFLAGS += -O2

GCCONLYFLAGS+=-ffreestanding # Freestanding compile

>
>> 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.

Almost zero. Templates can lead to additional code (.text) footprint
when overused, which can impact performance due to cache loading. The
inline keyword must be used judiciously.

Using C++ as "C with Classes" for embedded and bare-metal code is
good - you get the data encapsulation and inheritance provided by
the class keyword which helps with design and maintainence.

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.

scott

[Wouter van Ooijen]

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

[David Brown]

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%20-%20RainerGrimm.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.

Agreed.

[Scott Lurndal]

Wouter van Ooijen <wou...@voti.nl> writes:

>Scott Lurndal schreef op 28-Jan-14 5:18 PM:

>> 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
>

Or, you can do this to handle static constructors without libc, if you like:

Linker script:

. = ALIGN(32);
_srodata = .;
.rodata : {
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r*)
*(.got)
*(.got.*)

__CTOR_LIST__ = .;
LONG((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
*(.ctors)
LONG(0)
__CTOR_END__ = .;

__DTOR_LIST__ = .;
LONG((__DTOR_END__ - __DTOR_LIST__) / 8 - 2)
*(.dtors)
LONG(0)
__DTOR_END__ = .;
}
_erodata = .;


util/cppsupport.cpp:

extern void (*__CTOR_LIST__[])();

/*
* This is called by setup64.S to call the constructors of global objects,
* before it calls dvmm_bsp_start().
*
* GNU LD lays out the __CTOR_LIST__ as an array of function pointers. The
* first element of the array (index == 0) contains an integer which
* represents the value derived from subtracting two from the actual number
* of entries in the table. Thus the content of the first element is
* one less than the index of the last entry in the table.
*
* Call in reverse order XXX - why? Check crt0.o for canonical behavior
*/
extern "C" void
__call_constructors()
{
size_t count = *(size_t *)__CTOR_LIST__;

for(count++; count; --count) {
__CTOR_LIST__[count]();
}
}

setup64.S:

...
#
# Clear BSS
#
testl $1, %ebx # BSP or AP?
jnz 1f # AP, skip clear BSS & constructors

xorq %rax, %rax
leaq _sbss(%rip), %rdi
movq $0, %rcx
leaq _ebss(%rip), %rcx
subq %rdi, %rcx
rep stosb

pushq %rsi # Save RSI, since we'll need it later.
#
# Invoke the debugger early initialization function
#
movabsq $debugger, %rdi # Set this
movabsq $_ZN10c_debugger10early_initEv, %rcx # Call ::early_init
call *%rcx

#
# Invoke global C++ constructors.
#
movabsq $__call_constructors, %rcx
call *%rcx

popq %rsi # Restore RSI.
#
# Invoke C++ code. Pass begin and end address of memory map.
#
1:
movq $512, %rax # Starting with 512 bytes
subq %rsi, %rax # Subtract remaining
addq $0x90000, %rax # e820 data map address

# Use x86_64 calling conventions
movq $0x90000, %rdi # Pass arg1 to main
addq %r12, %rdi # Rebase arg1

movq %rax, %rsi # Pass arg2 to main
addq %r12, %rsi # Rebase arg2
movq %r15, %rdx # Arg3 is real-mode segment base
xorq %rbp, %rbp # Indicate end of stack for -fframe-pointer

movabsq $dvmm_bsp_start, %rcx # We use an indirect jump to invoke main
testl $1, %ebx # BSP or AP?
jz 4f # BSP, use 'dvmm_bsp_start'

movabsq $dvmm_ap_start, %rcx # AP, use 'dvmm_ap_start'
4: call *%rcx # because it is more than 2GB away from here

[Jorgen Grahn]

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 Grahn]

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 ...

[Richard Damon]

On 1/28/14, 11:18 AM, Scott Lurndal wrote:
> Wouter van Ooijen <wou...@voti.nl> writes:
>> Richard Damon schreef op 28-Jan-14 3:00 PM:
>>

>>> 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.
>
> Almost zero. Templates can lead to additional code (.text) footprint
> when overused, which can impact performance due to cache loading. The
> inline keyword must be used judiciously.

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.

I actually find more problems with template libraries in large machines,
as once you get to dynamic linked/shared libraries, you can start to run
into problems of getting the templates to be in the right piece of code.

[see.my....@gmail.com]

> 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

[Wouter van Ooijen]

see.my....@gmail.com 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

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> Almost zero. Templates can lead to additional code (.text) footprint
> when overused, which can impact performance due to cache loading. The
> inline keyword must be used judiciously.

Using templates can increase the size of the executable beyond what's
absolutely necessary, but they can also actually *decrease* it,
compared to the alternatives. This is because templates allow the
compiler to optimize the code on a type-by-type basis. (Heck, in some
cases the compiler can even optimize portions of the code away, by
evaluating it at compile time and putting just the result in the executable
binary.)

One common problem with templates is that many people get the wrong
impression when they observe how they apparently affect executable
sizes. The problem is that they often, inadvertently, compile with
debug and symbol information, and with templates the symbol names
tend to be larger than with non-templated code (sometimes significantly
larger). Thus such an executable file can be larger when using templates,
until you strip it. But many people don't know this.

If we look at the *actual* executable code that's generated by the
compiler, whether using templates increases, decreases or retains
the size, depends on what you would consider the *alternative* to
templates. If you would need to reuse the same routines with different
types, how would you do it without templates? Depending on your
solution you might actually find that, ironically, your solution
results in a larger (and often slower) binary than with templates.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[David Brown]

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]

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.

[Alf P. Steinbach]

On 25.01.2014 17:48, deepadi...@gmail.com 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

[Robert Wessel]

On Wed, 29 Jan 2014 15:01:04 +0100, "Alf P. Steinbach"
<alf.p.stein...@gmail.com> wrote:

>On 25.01.2014 17:48, deepadi...@gmail.com 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.

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).

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.

Of course, bad implementations can make any of that worse.

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?

A more useful argument against exception in some environments is that
they don't have a good context in which to work. Consider an
interrupt handler in a device driver called by the OS - you're not
going to be able to propagate an exception back past the call from the
OS.

[Alf P. Steinbach]

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.

[Wouter van Ooijen]

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

[Jorgen Grahn]

/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?

[Wouter van Ooijen]

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