C vs C++ in Embedded Systems?

In article <lKBKd.1489$S3.47@newsread2.news.atl.earthlink.net>, 
see@sig.com says...
> 
> An RTOS requires you _don't_ use OO.  I'm sure someone has done
> it, though.

I use Nucleus Plus Plus, which is an OO wrapper around a C-based RTOS.
It makes working with the RTOS a pleasure.

--Gene

Tauno Voipio wrote:

> The real problem with embedded C++ is the non-transparency
> of the language: a seemingly innocent piece of code may
> generate a translated code behemoth.

Isn't this also the case for C library functions or even assembly 
language macros?  In all cases, the solution is to know your tools very 
well.  C++ gets to be "transparent" when you become an expert with the 
language.  As with C compilers, if you're in doubt, look at the 
generated assembly.  It's actually pretty easy to avoid code bloat in 
C++ if you're careful.
For instance:
- avoid virtual base classes
- don't use multiple inheiritance
- avoid templates where practical

Modern C++ compilers tend to be pretty smart if used wisely.

Ed

On 2005-01-29, Ed Beroset <beroset@mindspring.com> wrote:
> Tauno Voipio wrote:
>
>> The real problem with embedded C++ is the non-transparency of
>> the language: a seemingly innocent piece of code may generate
>> a translated code behemoth.
>
> Isn't this also the case for C library functions

Sure.  But you know when you're calling a library function, and
you know what the code in the library function is.

> or even assembly language macros?

Same answer

> In all cases, the solution is to know your tools very well.
> C++ gets to be "transparent" when you become an expert with
> the language.

The problem is that the C++ language it's several orders of
magnitude more complicated than most other languages.  99% of
the people writing C++ aren't experts in C++.  It far easier to
be an expert in C.  Or Python.  Or Modula-3, or Ada, or Pascal,
or ...

> Modern C++ compilers tend to be pretty smart if used wisely.

But they aren't.

-- 
Grant Edwards                   grante             Yow!  PEGGY FLEMING is
                                  at               stealing BASKET BALLS to
                               visi.com            feed the babies in VERMONT.

Grant Edwards wrote:
> On 2005-01-29, Ed Beroset <beroset@mindspring.com> wrote:
> 
>>Tauno Voipio wrote:
>>
>>
>>>The real problem with embedded C++ is the non-transparency of
>>>the language: a seemingly innocent piece of code may generate
>>>a translated code behemoth.
>>
>>Isn't this also the case for C library functions
> 
> 
> Sure.  But you know when you're calling a library function, and
> you know what the code in the library function is.

Don't be so sure.  As an example, consider the C language fragment:

int numerator = 35323;
int denominator = 1038;
int answer = numerator / denominator;

On an 8-bit micro with no native divide instruction, this can generate 
quite a bit of code even though there was no obvious library call. 
Obviously, for that kind of micro, C++ would have the same problem.

>>or even assembly language macros?
> 
> Same answer

And same response!  For an extreme example see HLA. 
http://webster.cs.ucr.edu/AsmTools/HLA/index.html

>>In all cases, the solution is to know your tools very well.
>>C++ gets to be "transparent" when you become an expert with
>>the language.
> 
> The problem is that the C++ language it's several orders of
> magnitude more complicated than most other languages.  99% of
> the people writing C++ aren't experts in C++.  

Nobody uses all of the language, so you don't have to be expert in all 
of it -- just the subset that you use.

> It far easier to
> be an expert in C.  Or Python.  Or Modula-3, or Ada, or Pascal,
> or ...

That's true, but if you're tackling a job with C++, it's often of the 
larger and more complex variety anyway, so you can either become expert 
on your own implementation of the system in C (which is fairly useless 
on the next job) or become expert on a complex but powerful language 
like C++.  Just for scale here, when I say "larger and more complex," 
I'm thinking of embedded projects that would be more than 100k lines of 
C code.

>>Modern C++ compilers tend to be pretty smart if used wisely.
> 
> But they aren't.

Automobiles tend to kill people because most people aren't expert 
drivers.  Therefore everyone should avoid driving.  That's sage advice, 
but you need to evaluate both the cost and the benefit.  Weighing the 
risks and mitigating them by improving your own skills, there are many 
transportation problems for which an automobile is a good answer because 
the benefits outweigh the risks, just as there are many programming 
problems for which C++ is a good answer because the benefits outweigh 
the risks.

I don't say that everyone should always use C++, but I think it's 
equally poor advice to say "never use C++ for embedded systems."

Ed

Tim Wescott wrote:
> Grant Edwards wrote:
> 
>> On 2005-01-28, Mayank Kaushik <prehistorictoad2k@yahoo.com> wrote:
>>
>>
>>> How do C and C++ compare vis-a-vis Embedded Systems?
>>
>>
>>
>> IMO, nobody should write a line of source code for an embedded
>> system unless they know ahead of time what code (more or less)
>> the compiler is going to generate.  That's possible with C.
>>
>> The C++ language is so unbelievably complex and "feature"
>> ridden, that nobody ever quite knows what's going to happen
>> when they write a line of code.
>>
>> IOW, I don't approve of C++ for embedde use.  Or for
>> non-embedded use, actually.
>>
> Yes on paying attention to compiler output, no on C++ paranoia.
> 
> As long as you avoid the really dippy language features and don't touch 
> the C++ standard libraries with a 10-foot pole you'll do OK.  Most 
> compilers only pull in the extra baggage for a feature if you use it, so 
> if you don't use the feature you're OK.  And if you have a compiler that 
> _does_ pull in the baggage then don't use it!
> 
> I've been programming headless embedded systems in C++ for eight years 
> now with great success.  It enables faster programming on large 
> applications, easier factoring of jobs among a team, and significantly 
> easier design-for-reuse.  It _does_ require careful programming, and an 
> idiot at the keyboard will bring you down faster than anything, but you 
> get that with any programming language.

I'll agree with the "idiot at the keyboard" comment, but disagree on not 
being paranoid about C++. Paranoia doesn't mean "don't use it ever," it 
means "be concerned/afraid/careful."

This is a subject that comes up from time to time. One of the previous 
times, I printed out a comment in the thread, just because it had very 
good information about _why_ you should be paranoid about C++ in 
embedded systems. It was written by Jonathon Kirwan, and he called it 
"My World and Welcome To It." I've kept it around since then, because I 
work on similarly small systems, but I'm starting to do more with 
32-bitters and need to know about C++ since our customers ask for/about it.

You can find Mr. Kirwan's post here: 
http://groups-beta.google.com/group/comp.arch.embedded/browse_thread/thread/36d06d841b7c8422/8c402e042e26d771?q=kirwan+%22my+world%22+C%2B%2B&_done=%2Fgroups%3Fq%3Dkirwan+%22my+world%22+C%2B%2B%26hl%3Den%26lr%3D%26tab%3Dng%26ie%3DUTF-8%26sa%3DN%26&_doneTitle=Back+to+Search&&d#8c402e042e26d771

-- 
wheels

On 2005-01-29, Ed Beroset <beroset@mindspring.com> wrote:

>>>>The real problem with embedded C++ is the non-transparency of
>>>>the language: a seemingly innocent piece of code may generate
>>>>a translated code behemoth.
>>>
>>>Isn't this also the case for C library functions
>> 
>> Sure.  But you know when you're calling a library function, and
>> you know what the code in the library function is.
>
> Don't be so sure.  As an example, consider the C language fragment:
>
> int numerator = 35323;
> int denominator = 1038;
> int answer = numerator / denominator;
>
> On an 8-bit micro with no native divide instruction, this can generate 
> quite a bit of code even though there was no obvious library call.

But on an 8-bit micro with no native divide instruction, the
"/" is an obvious library call.  Just as any floating point
operator is a function call on a processor without FP hardware.

> That's true, but if you're tackling a job with C++, it's often
> of the larger and more complex variety anyway, so you can
> either become expert on your own implementation of the system
> in C (which is fairly useless on the next job) or become
> expert on a complex but powerful language like C++.

But there are plenty of powerful but simple languages that
would work just as well.  Power != complexity.  It's a shame
that an entire generation of developers seem to think that to
get the benefits of OO you have to use a complex language like
C++.  C++ is just plain badly designed.  It's overly complex,
and it's dangerous.  Neither of which are required to get the
benefits of encapsulation and OO.

-- 
Grant Edwards                   grante             Yow!  I'm meditating on
                                  at               the FORMALDEHYDE and the
                               visi.com            ASBESTOS leaking into my
                                                   PERSONAL SPACE!!

"Grant Edwards" <grante@visi.com> wrote in message
news:41fbda95$0$15883$a1866201@visi.com...
> But there are plenty of powerful but simple languages that
> would work just as well.  Power != complexity.  It's a shame
> that an entire generation of developers seem to think that to
> get the benefits of OO you have to use a complex language like
> C++.  C++ is just plain badly designed.  It's overly complex,
> and it's dangerous.  Neither of which are required to get the
> benefits of encapsulation and OO.

Well said. That's exactly my viewpoint in all respects.

>> C++ is just plain badly designed. <<

Worth repeating just to savour ;). It's a halfway-house hack. ISTR that even
Bjarne said as much.

Steve
http://www.fivetrees.com

Steven R. Wheeler wrote:

>You can find Mr. Kirwan's post here: 
>http://groups-beta.google.com/group/comp.arch.embedded/browse_thread/thread/36d06d841b7c8422/8c402e042e26d771?q=kirwan+%22my+world%22+C%2B%2B&_done=%2Fgroups%3Fq%3Dkirwan+%22my+world%22+C%2B%2B%26hl%3Den%26lr%3D%26ta

Not very easily.  Try this instead:

http://groups-beta.google.com/group/comp.arch.embedded/msg/8c402e042e26d771

On Sat, 29 Jan 2005 11:33:59 -0700, "Steven R. Wheeler"
<swheeler843@earthlink.net> wrote:

>I'll agree with the "idiot at the keyboard" comment, but disagree on not 
>being paranoid about C++. Paranoia doesn't mean "don't use it ever," it 
>means "be concerned/afraid/careful."

Being "on guard" with C++ is a good thing.

>This is a subject that comes up from time to time. One of the previous 
>times, I printed out a comment in the thread, just because it had very 
>good information about _why_ you should be paranoid about C++ in 
>embedded systems. It was written by Jonathon Kirwan, and he called it 
>"My World and Welcome To It."

Actually, it is Jonath(a)n and "My World and Welcome To It" was the heading for
a section of what I wrote, not the entire body.  But it's a great title for the
whole thing, so I accept your naming!  :)

>I've kept it around since then, because I 
>work on similarly small systems, but I'm starting to do more with 
>32-bitters and need to know about C++ since our customers ask for/about it.
>
>You can find Mr. Kirwan's post here: 
>http://groups-beta.google.com/group/comp.arch.embedded/browse_thread/thread/36d06d841b7c8422/8c402e042e26d771?q=kirwan+%22my+world%22+C%2B%2B&_done=%2Fgroups%3Fq%3Dkirwan+%22my+world%22+C%2B%2B%26hl%3Den%26lr%3D%26tab%3Dng%26ie%3DUTF-8%26sa%3DN%26&_doneTitle=Back+to+Search&&d#8c402e042e26d771

Perhaps a little more readable, standing by itself in this way:
  http://groups-beta.google.com/group/comp.arch.embedded/msg/8c402e042e26d771

Thanks for your kind words, too.

I like to test myself and see if I can produce, by hand, the same assembly code
from a small function I write.  In C, I can almost always do that for any CPU
I'm familiar with and for any C compiler I'm faced with, within a reasonable
range of "closeness."  I'm quite facile with that ability and can translate, for
example, a great range of C functions into x86 assembly as fast as I can write
it without missing a beat.  When I taught university level computer architecture
and assembly programming classes, I'd often demonstrate this facility in front
of the class, letting them pick the C code (which they learned in an earlier
year there) and having me move to the 2nd chalk board and write it out as the
Microsoft C compiler would produce it.  I would do this as fast as I could
write.  And I hit it exactly.  Made a nice demonstration.

It was in trying to do this for C++ that I ran into serious trouble regarding my
own abilities here.  I quickly learned just how many seemingly innocuous
snippets of C++ code would trip me up.  As I learned to deal with those, I kept
finding still new ones.  And so it went.  I soon learned just how much more
difficult it was and, in that realization, I learned some very great respect for
C++ and probably some very great dread and fear, as well.

To use C++ well and wisely in the kind of embedded systems I discussed then, one
must have a kind of trembling respect for it and to spend time studying it and
understanding it before putting one's hand out to actually work with it.  C++ is
much like a tiger, in that way.  If you are ignorant, you could as quickly lose
your hand as keep it.

Jon

Steven R. Wheeler wrote:
-- snip -->
> I'll agree with the "idiot at the keyboard" comment, but disagree on not 
> being paranoid about C++. Paranoia doesn't mean "don't use it ever," it 
> means "be concerned/afraid/careful."

Maybe to you.  Webster's says it means "a tendency ... toward excessive 
or irrational suspiciousness and distrustfulness ...". 
http://www.meriam-webster.com/cgi-bin/dictionary?book=Dictionary&va=paranoia&x=0&y=0

We agree, however, that taking care is good, but knee-jerk rejection is bad.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com