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
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
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
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
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
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
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.
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 :-)
Worst. IDE. Ever.
-- Rich Webb Norfolk, VA
"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.
"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.
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
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?
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
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."
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.
Troll yourself, mister :-X
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
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
My kinda guy ;).
Steve PS: Curmudgeons-R-Us
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
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.
[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
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.