C vs C++ in Embedded Systems?

"Grant Edwards" <grante@visi.com> wrote in message
news:41fa8e85$0$11509$a1866201@visi.com...
> On 2005-01-28, Mayank Kaushik <prehistorictoad2k@yahoo.com> wrote:
> IOW, I don't approve of C++ for embedde use.  Or for
> non-embedded use, actually.

My kinda guy ;).

Steve
PS: Curmudgeons-R-Us
http://www.fivetrees.com

"Antti Keskinen" <antti.keskinen@REMOVEME.koti.luukku.com> wrote in message
news:cteabq$1l40$1@news.cc.tut.fi...
> C is more popular and more 'streamlined' (doesn't contain anything fancy)
> for smaller embedded systems. It can't be used for true object-oriented
> programming, but who needs OO on 8-bit processors ?

I disagree. I consider OO at least as much a design technique as a language
feature.

I agreed with the rest of your post, though ;).

Steve
http://www.fivetrees.com

Mayank Kaushik wrote:
> Hi everyone,
> 
> Well, i suppose all that everyone said about C++ stands from an
> "application development" point of view...but what benefits would C++
> deliver if used for something more hardware-oriented, like, say, device
> drivers?
> 
> And wheres the guy who talked about trolls :-O
> 
> regards
> Mayank
> 

Efforts to introduce C++ into the Linux kernel have gone nowhere.
C excels as a portable low-level language. C++ is much more suited
to managing complexity though OO.

<pm940@yahoo.com> wrote in message
news:1106951439.353545.210830@z14g2000cwz.googlegroups.com...
> I have used C++ in a number of embedded projects.  This was back in the
> mid-90s, and we had some rules to stop programmers going overboard with
> language features to the extent that others could not determine what a
> line of code did by simply reading it.

<Applause>

> 1. Don't use exceptions or templates - these are "heavy weight"
> features which take a lot of code and/or runtime.
> 2. Don't use operator overloading:  a = b - c should not invoke 100,000
> lines of code.
> 3. Don't use polymorphic functions.  With implicit type conversion it's
> hard to figure out which out of the 3 versions of a function will be
> called, given a specific line of code.

<More applause>

[One more from me: use constructors/destructors for class data
initialisation only, not for functional work. (I.e. same idea: don't allow a
new instantiation to invoke lengthy/functional code.)]

I salute you, sir.

I've read so much good sense in this thread so far I've come over all funny.

Steve
http://www.fivetrees.com

"Darin Johnson" <darin_@_usa_._net> wrote in message
news:cu1k6pwoqaa.fsf@nokia.com...
> pm940@yahoo.com writes:
> Exceptions can be efficient in comparison to the alternative of
> putting explicit error checks everywhere.

I see this justification a lot, and in conventional sequential code it makes
sense. However, anytime I run into these issues I wrap the throw scope in a
state machine, and put the error check in *one* obvious place. The overhead
of "explicit error checks everywhere" doesn't apply. I don' need no
steenking exceptions ;).

Going back to the (most) recent discussion about RTOSs: I'm wary of the
design approach that figures there's another layer watching out for my ass.
Diapers don't make for good housetraining.

Steve
http://www.fivetrees.com

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote in message
news:1106972357.942219.68660@c13g2000cwb.googlegroups.com...
> Well, i suppose all that everyone said about C++ stands from an
> "application development" point of view...but what benefits would C++
> deliver if used for something more hardware-oriented, like, say, device
> drivers?

C++ specifically or OO in general?

There's a good deal of sense in encapsulating (i.e. decoupling) e.g. a comms
driver and(/from) the rest of the application. But that's just good,
sensible decomposition. I don't believe there's anything inherent in C++
that changes/enhances this.

Steve
http://www.fivetrees.com

Ed Beroset wrote:

> Nicholas O. Lindan wrote:
> 
>>> It _does_ require careful programming, and an idiot at the keyboard 
>>> will bring you down faster than anything,
>>
>>
>> Exactly.  That's one reason I don't even like C for embedded -- there 
>> is _always_ at least one idiot on the program.  Sometimes
>> that idiot is me.  The thought of C++ brings me out in hives.

And an idiot writing in assembly is somehow better?
>>
>> My perspective is from a greater distance: I grew up on Algol 60, I 
>> still use PL/Mxxx for embedded systems.  I don't worry about
>> the run time library or the compiler.  And I do remember a time
>> when PL/M was not to be trusted [PL/M-80 _was_ really dreadful].
> 
That's interesting.  I've fixed idiot PL/M-96 code.  It doesn't matter 
_what_ the language is -- I've found idiot Ada code, and I'm not even an 
Ada programmer (great fun:  them: "our code is in Ada, the language of 
the gods, it can't possibly have bugs"  me: "what's this discrepancy 
between line 123 and line 154?"  them: "oh sh--").
> 
> Time marches on.  Using C++ for embedded work is certainly not the 
> universally correct choice (no language is, IMHO) but it's not 
> necessarily poison either.  Like every other tool (PL/M, Forth, 
> assembly, C) you have to invest some time in learning about the proper 
> application of the tool to make good use of it.  For most of the 
> small-ish embedded systems I've worked on, C++ was probably not the best 
> fit, and compiler suppport was spotty at best.  However, I have also 
> worked on some higher end embedded projects (32-bit CPU, lots of 
> mmemory, many communication options) for which C++ was absolutely the 
> most reasonable choice to make thing work.
> 
> IMHO, it's a matter of scale.  If you are trying to create a larger, but 
> still embedded system, consider C++.  OTOH, if you can't find a C++ 
> compiler for your 8-bit micro, don't try to force-fit C++.
> 
Everything I've done in C++ has been in high-end 16-bit and low-end 
32-bit processors.  I probably wouldn't use it on an 8-bit processor 
unless I had compelling reasons.

-- 

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

Steve at fivetrees wrote:
> "Grant Edwards" <grante@visi.com> wrote in message
> news:41fa8e85$0$11509$a1866201@visi.com...
> 
>>On 2005-01-28, Mayank Kaushik <prehistorictoad2k@yahoo.com> wrote:
>>IOW, I don't approve of C++ for embedde use.  Or for
>>non-embedded use, actually.
> 
> 
> My kinda guy ;).
> 
> Steve
> PS: Curmudgeons-R-Us
> http://www.fivetrees.com
> 
> 

Me too.

For *real* object-oriented coding, C++ is a bastard, it's
not a super-assembler (like plain C), nor a real object
language (like Eiffel, Java & co).

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.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Nicholas O. Lindan wrote:

>As the promos said "Don't reinvent it, inherit it!".  One line and
>the whole world hops on for the ride.

My philosophy is, "don't inherit it, cut and paste it into the 
source!"  This allows code reuse in Assembly Language, Forth, 
BASIC, and yes, even in C++. <grin>

Guy Macon <http://www.guymacon.com/>

Neil Kurzman wrote:

>That is like asking what is the best size tire for a car.  "Embedded
>Systems" range from slow 8bit CPUs with less than 1 K of RAM to 32 and 64
>bit  gigahertz  CPUs with Megs of RAM.

HEY! What about *my* favorites; 4-bit CPUs with 64 nybbles of RAM?

Not a lot of call for C++ on those... :)