EmbeddedRelated.com
Forums

C vs C++ in Embedded Systems?

Started by Mayank Kaushik January 28, 2005
On Fri, 28 Jan 2005 21:46:25 +0100, "WaldemarIII" <bleek004@hotmail.com>
wrote:

>"Chris Hills" <chris@phaedsys.org> schreef in bericht >news:UNSnQKCzNo+BFAck@phaedsys.demon.co.uk... >> In article <1106934623.176433.166230@z14g2000cwz.googlegroups.com>, >> Mayank Kaushik <prehistorictoad2k@yahoo.com> writes >> >Hi, >> > >> >How do C and C++ compare vis-a-vis Embedded Systems? And how about with >> >respect to any kind of hardware-level programming? Just asking out of >> >curiosity, so plz dont qualify your answer! >> >> It's quite simple. There are no (or virtually no) C++ compilers for 8 >> bit systems. > >Not true! Take a peek at e.g. the Metrowerks CodeWarrior for HC08.
Worst. IDE. Ever. -- Rich Webb Norfolk, VA
"Antti Keskinen" <antti.keskinen@REMOVEME.koti.luukku.com> wrote

> C is more popular and more 'streamlined' [than C++]
I think you mean more 'naked'.
> [C] can't be used for true object-oriented programming
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.
> but who needs OO on 8-bit processors?
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.
> Designing something like an RTOS requires OO, presumably,
An RTOS requires you _don't_ use OO. I'm sure someone has done it, though.
> but an RTOS on an 8-bit processor?
There are more RTOS's running on 8-bit processors than any other operating system on Earth.
> Isn't that a bit like overshoot?
Try reducing the gain or adjust the peaking capacitor. -- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. To reply, remove spaces: n o lindan at ix . netcom . com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
"Tim Wescott" <tim@wescottnospamdesign.com> wrote

> I've been programming headless embedded systems in C++ for eight years > now with great success.
Oh dear, I knew someone was doing it.
> As long as you avoid the really dippy language features
Er, stick to C? The advantage of OO/C++ is that it finally delivers on what modular programming only promised: great encapsulation and clean division of functions.
> and don't touch the C++ standard libraries with a > 10-foot pole you'll do OK.
As the promos said "Don't reinvent it, inherit it!". One line and the whole world hops on for the ride.
> 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. 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]. -- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. To reply, remove spaces: n o lindan at ix . netcom . com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
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. > > 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].
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++. Ed
Nicholas O. Lindan wrote:
> > 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.
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
> "Why not SmallTalk? Gee I wonder what happens to the > landing gear if it's time to do garbage collection."
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.
> In ten/twenty/fifty years OO will be a quaint anachronism > sitting on the museum shelf right next to the GOTO statement.
IMHO, it's more likely that OO will still be used, and you and I will be sitting on the museum shelf. ;-) Ed
pm940@yahoo.com writes:

> 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.
This wasn't the main reason most people limited these features. A major problem was often that these "advanced" features were poorly implemented, or not reliably portable across compilers. Most of these "heavy weight" features can be used in a light weight manner with a bit of thought.
> 1. Don't use exceptions or templates - these are "heavy weight" > features which take a lot of code and/or runtime.
Exceptions can be efficient in comparison to the alternative of putting explicit error checks everywhere. A problem with using them though is that if you've got a significant body of existing code then you've essentially got to restructure it all. If you try to add exceptions a little bit at a time you end up with an extra exception overhead in addition to the pre-existing error checking overhead. Templates can be used just as smart type-checked macros. Just because the STL uses templates doesn't mean that all template use has to be so inefficient. In particular, one could create a straight-forward list-of-void* container, then use generic templates to typecast everything safely to have list-of-pointer-to-anything containers. No extra run-time lines of code.
> 1. Don't use exceptions or templates - these are "heavy weight" > features which take a lot of code and/or runtime.
Exceptions can be efficient in comparison to the alternative of putting explicit error checks everywhere. A problem with using them though is that if you've got a significant body of existing code then you've essentially got to restructure it all. If you try to add exceptions a little bit at a time you end up with an extra exception overhead in addition to the pre-existing error checking overhead. Templates can be used just as smart type-checked macros. Just because the STL uses templates doesn't mean that all template use has to be so inefficient. In particular, one could create a straight-forward list-of-void* container, then use generic templates to typecast everything safely to have list-of-pointer-to-anything containers. No extra run-time lines of code. -- Darin Johnson "You used to be big." "I am big. It's the pictures that got small."

Mayank Kaushik wrote:

> Hi, > > How do C and C++ compare vis-a-vis Embedded Systems? And how about with > respect to any kind of hardware-level programming? Just asking out of > curiosity, so plz dont qualify your answer! > > Regards > Mayank
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.
Bob wrote:
>Is it just me, or does the email address >"prehistoric toad 2k" sound like a troll? > > Bob
Troll yourself, mister :-X
On 2005-01-29, Ed Beroset <beroset@mindspring.com> wrote:

> 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.
I'm convinced that most embedded C++ apps would have been better written in Modula-3 or some other language that's not just a huge collection of dangerous features. -- Grant Edwards grante Yow! I want EARS! I at want two ROUND BLACK visi.com EARS to make me feel warm 'n secure!!
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