C vs C++ in Embedded Systems?

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

Reply to
Mayank Kaushik
Loading thread data ...

In article , Mayank Kaushik writes

It's quite simple. There are no (or virtually no) C++ compilers for 8 bit systems.

16/32/64 bit systems do have C++

What do you mean how do they compare? In what sense?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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.

--
Grant Edwards                   grante             Yow!  Not SENSUOUS... only
                                  at               "FROLICSOME"... and in
 Click to see the full signature
Reply to
Grant Edwards

I prefer C++ when I have the resources because I can use the STL and have all the other benefits of object oriented programming. You can always drop back into C if you want to. However on Linux I find that using C++ libraries makes programs 10 times bigger and compile 10 times slower. On small processors you don't have the option of C++. Peter

Reply to
Peter
[original question pasted to the bottom for humor value]

I agree 1000% (not a typo)

Not true for me, but I don't use exceptions, templates, or iostreams. Heck, I don't even use heap if I can avoid it. The compiler (MSC++ 8.0 that came with MSVC 1.5 or there abouts) has been generating perfectly fine code for my 80C186 projects since 1995. But, that's just my experience. Everyone should use the toolset that works for them.

I guess it *has* been at least a month since the last C vs C++ religious battles were waged here ;-) Is it just me, or does the email address "prehistoric toad 2k" sound like a troll?

Bob

Reply to
Bob

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.

  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.

We mainly used C++ for its class hierarchies, virtual functions, etc. for all the normal object-oriented advantages, but we restricted our use to make sure we never lost track of what was a function call vs. what was an instrinsic machine operation.

We were very successful. Bringing C programmers up to speed with this "reduced" C++ was very fast, and we made sure that C++ experts did not write code that was too clever for the masses.

I guess the bottom line is that, like all language choices, "it depends". It depends on tool support, personal preference, even political will.

C++ can do everything C can do... only with uglier (mangled) function names :-)

Reply to
pm940

Worst. IDE. Ever.

--
Rich Webb   Norfolk, VA
Reply to
Rich Webb

"Antti Keskinen" wrote

I think you mean more 'naked'.

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.

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.

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

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

Try reducing the gain or adjust the peaking capacitor.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan

"Tim Wescott" wrote

Oh dear, I knew someone was doing it.

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.

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

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.
 Click to see the full signature
Reply to
Nicholas O. Lindan

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

Reply to
Ed Beroset

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?

formatting link

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.

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

Ed

Reply to
Ed Beroset

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.

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.

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."
 Click to see the full signature
Reply to
Darin Johnson

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.

Reply to
Neil Kurzman

Troll yourself, mister :-X

Reply to
Mayank Kaushik

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
 Click to see the full signature
Reply to
Grant Edwards

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

Reply to
Mayank Kaushik

My kinda guy ;).

Steve PS: Curmudgeons-R-Us

formatting link

Reply to
Steve at fivetrees

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

formatting link

Reply to
Steve at fivetrees

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.

Reply to
Second Amendment Loves You

[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

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.