C vs C++ in Embedded Systems? - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

I agree, and would go further to suggest that it's part of a design
methodology that doesn't admit to "error" conditions: everything that can
happen is something that can happen, and should be designed-for.  If you
keep everything in-band, then there is no scope for "exceptions" as such,
although you may very well need to define specific "error states" as part
of the system decomposition.  I suspect that this strategy may be brittle,
and may not scale up to things as complicated as graphical workstations,
but it does work nicely on single-chip coded-to-the-metal embedded
projects, in my experience.

--
Andrew


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it
to
not
tends
of

Nicely put. That's also been my experience.

Steve
http://www.fivetrees.com



Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

Exceptions don't make any difference here. No matter whether you use
error codes or exceptions you'll always have to deal with them one way
or another. Exceptions only provide a mechanism to report problems.
Dealing with them remains the job of the programmer.

Quoted text here. Click to load it

I don't doubt that it works well for small applications, but - as you
say - it does not scale very well.

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
We've slightly trimmed the long signature. Click to see the full one.
Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

This isn't what I meant at all, but it's hard to give a non-specific,
general example.  Here's a (probably flawed) one:

Say that you have an application that wants a reciprocal.  You might be
able to use domain knowledge of the applciation to define a "reciprocal"
function that returns a saturation value if the input is zero (or
negative, perhaps) rather than throwing an exception that must be
explicitly caught by the caller.  By encapsulating what might be an
exceptional condition in a fully general function into the *spec* of the
specific function, you can completely remove the exception and the need to
deal with it at a high level, by completely dealing with the situation at
the lower level.

The brittleness arises because this doesn't look as though it
would encourage the development of fully (or maximally) general subroutine
libraries. Perhaps there's a happy medium where specialized (wrapped)
versions of library functions that may throw exceptions are always used,
where the exception is caught at the lowest level (the wrapper), and
dealt-with appropriately (for the application). That doesn't sound a whole
lot different to just checking for the returned error condition, though...

--
Andrew


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

I might agree if the saturation value is INF (which is often supported
with FP arithmetic). Then, further calculation will yield *obviously*
wrong results and you also don't need to hand-propagate errors.

Quoted text here. Click to load it

Ok so far...

Quoted text here. Click to load it

Nope. Unless you're going to discard the results (which would defeat the
pupose of the calculation), someone or something actively has to decide
that the results are wrong and take action on that fact. This decision
is either made in program code or by a human reading some kind of
output. There definitely will be a check *somewhere*, otherwise the
calculation is useless.

Quoted text here. Click to load it

IME, this is typically not possible. An application using a library
often employs its own layers to simplify library usage. Errors reported
from the library almost always need to be propagated through these
layers so that they can be dealt with...

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
We've slightly trimmed the long signature. Click to see the full one.
Re: C vs C++ in Embedded Systems?


Quoted text here. Click to load it

Hand-propagate errors?  That's what signaling NANs an silent NANs
were invented for.



Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

Well, INF is propagated automatically as well, isn't it? Moreover, if
you make further calculations with INF values (e.g. INF*0), NAN values
often result...

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
We've slightly trimmed the long signature. Click to see the full one.
Re: C vs C++ in Embedded Systems?

Quoted text here. Click to load it

Exactly so.  In many cases, no need to hand-propagate errors.


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

Decomposition - at least the kind I know - makes call trees deeper and
not more shallow, so you'd have even more need for exceptions. The only
way I see how you can flatten call trees in state machines is:
1) You make your functions contain more statements (e.g. instead of
calling d() from c() you simply copy-paste d()'s function body into
c()).
2) Because 1 leaves you with inordinately long function bodies, you
break them up into handy pieces and have your fsm call them in the right
sequence.

The problems I see with this approach is that it leads to code
duplication and obfuscation, just to avoid exceptions.

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
We've slightly trimmed the long signature. Click to see the full one.
Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

No, that's not what I mean. Not sure I can describe what I *do* mean, though
;).

Quoted text here. Click to load it

Not qualities I would tolerate. No; if anything I believe my code is
clearer - simply because there is nothing going on that isn't visible, and
that I have to remember to clean up later...

Probably, exceptions in general are like everything else we've been
discussing - a tool that's appropriate in the right cases, and in the right
hands.

Steve
http://www.fivetrees.com



Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

<Applause>

Quoted text here. Click to load it

<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



Re: C vs C++ in Embedded Systems?

Quoted text here. Click to load it

I think you mean more 'naked'.

Quoted text here. Click to load it

Whooooo.  Sure can.  How about "object-assembler", commercial applications
got written in it.  Slick stuff, you wouldn't believe what you can get
an XT to do.

_ALL_ programming languages [allowing for enough memory and addressing]
are equivalent.  Look up 'Turing'.  And they are all _boring_, being
deterministic and all.

It is possible to get by with one instruction:

  "Move to A if the bit moved from B1 to B2 was a 1"

This would be a computer without opcodes or an instruction decoder,
just 3 addresses.  Tempting.

Quoted text here. Click to load it

Who needs OO on anything?  It is not ordained.  Until a few years
ago proposing C++ for an embedded system would be considered a
joke.  

   "Why not SmallTalk?  Gee I wonder what happens to the
    landing gear if it's time to do garbage collection."

In ten/twenty/fifty years OO will be a quaint anachronism
sitting on the museum shelf right next to the GOTO statement.

Quoted text here. Click to load it

An RTOS requires you _don't_ use OO.  I'm sure someone has done
it, though.

Quoted text here. Click to load it

There are more RTOS's running on 8-bit processors than any
other operating system on Earth.

Quoted text here. Click to load it

Try reducing the gain or adjust the peaking capacitor.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

Until a few years ago, proposing a microprocessor for many embedded
systems would have been considered a joke.  Now imagine that they get so
cheap that you have a keypad, RF tranceiver, display, battery and
microphone attached, and it's STILL cheap enough to be disposable.
Absurd, ain't it?

http://www.pcworld.com/news/article/0,aid,106116,00.asp

Quoted text here. Click to load it

You may know, but just for those watching, C++ does not employ any
garbage collection scheme (unlike Smalltalk and Java), and was developed
for and has been successfully used in telephone switches, which are most
certainly a real-time application.

Quoted text here. Click to load it

IMHO, it's more likely that OO will still be used, and you and I will be
sitting on the museum shelf.  ;-)

Ed


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

Yeah, but so was Erlang, and it's an OO-functional language with all the
usual ML-style garbage collection facities.  So I don't think that's a
great argument...

--
Andrew


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

Actually, that just bolsters the argument -- real time systems can be
built in a lot of different ways, including with C++.

Ed


Re: C vs C++ in Embedded Systems?
snipped-for-privacy@sig.com says...
Quoted text here. Click to load it

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

--Gene


Re: C vs C++ in Embedded Systems?



Quoted text here. Click to load it

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.

on the Low end C only in the mid to high end.  If the platform supports it
and you like it, go with the C++.
For big projects  maybe you have a better case for C++ over C.



Re: C vs C++ in Embedded Systems?
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


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

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.


Re: C vs C++ in Embedded Systems?
Quoted text here. Click to load it

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



Site Timeline