Technology question: why is it that for embedded programming (8- and 16-bit microprocessors, etc -- not so much CE etc.), the programming languages are not object oriented (i.e., C, not C++)? The advantages of OO are obvious, what is it that makes it not suitable for smaller processors? Is it that OO for some reason takes more resources? Is it the non-determinism (and perhaps lower reliability) associated with dynamically allocating objects? What are the reasons?
Thanks in advance!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Really?? Is there that much overhead for C++ relative to C?
If the difference was not that big (5-10%??), I would think that it would be perfectly viable in lots of applications, not every application consumes all the RAM.
For example this article
http://en.wikipedia.org/wi
refers to the "shortcomings of C++ for embedded apps", this is only referring to space, eh?
(Going to leave this open to get diverse opinions, will split points with all helpful answers.)
There are many implementations of C++ for microcontrollers, but usually in 8-bit microprocessor you need just a straightforward application with the best performance you can, there C languaje would be the prefered compiler AFTER assembly languagje.
16 bit microcontrollers usually have more memory, greater performance, lots of memory registers and a better memory scheme, that's why there are more compilers for 16 bits (and 32 bits of course).
Some simple task in C++ that you code with easy, generate a processor and memory overhead, like virtual functions. C languaje instructions, countersense, match one-by-one with microprocessor instructions.
The size difference between C and C++ becomes especially obvious when you make use of the STL or otherwise use templates heavily. It is also more space and often also performance efficient not to use complex linked libraries, but smaller pieces of code that can ideally be stripped down to the absolutly neccessary functionality for the intended use.
Another reason is that for some targets only C or crippled C++ compilers are available or only these compilers support the special memory layout of the target CPU (i.e. Keil) and thus C still remeins the the most portable language for embedded programming.
Besides that is embedded programming usually more focused towards a certain use compared to desktop or enterprise level applications. It doesn't need to have the same level of flexibilty at runtime. Embedded projects usually rely more on compile time flexibilty for which the plain old C preprocessor and makefiles are still sufficient in most cases (i.e. for different product variants).
Other OO-languages like Java turned out to be to heavy weight for 8 or 16-Bit CPUs. Some companies tried to establish Java as an alternative in this field (i.e. Dallas) but gave up in the meantime or are more focused on good C-support again.
Here's where I'm coming from: I've been functioning as sort of a safety engineer lately, and reviewing lots of commercial, old-ish (10+ years) embedded code for suitability for our safety applications. Almost all of it is flat C code, with lots and lots and lots of global variables. Very hard to understand and review and certify. This has reminded me how much safer OO code is, with the ability to encapsulate variables and complexity, the ability to limit the scope of variables and functions, the ease of reusing classes so they can really get mature.
So, I would leave out the templates and the complex libraries, but I'm surprised that you can't get enough of the ++ in there (is that the "crippled C++" you're referring to?) so that you can just have classes and objects. In my small experience it would greatly improve the state/quality of embedded programming.
Any thoughts?
I'm not sure when you would need a runtime library, would you need it to be able to use the OO stuff, classes, objects, inheritance, polymorphism, etc? I'd think all of those would just need compiler support, right?
I know, for example, MFC has a runtime library and .NET has a runtime library, but those are for the predefined classes like Window classes and control classes, right? Why would you need one just to use OO?
Maybe you'd like to check some sites linked from there: http://www.caravan.net/ec2
I believe that's the same software I sent the wiki link for above. Apparently EC++ "hasn't had a good reception" with programmers, and "if it isn't dead it ought to be." That's what started me off in this direction, I don't know why it's so technically hard, and why people don't seem to want it more. A sea of global variables is much harder to analyze and prove safe.
Although that page has some pros/cons, a slide show with techncial data, including shortcomings. Maybe that will be illuminating. Thanks.
Anyway thanks for the thoughts guys.
programming in C does not require you to make extensive use of global variables. In fact, I'd state that a (compilation unit) global variable here and there is OK, but don't overdo it.
You can most likely rewrite the code without as much global variables if you experience problems with them (which I can understand very well).
Just to confirm what's already been said : I think the main reason that C++ is not widely used for embedded systems, is that there just is no compiler support for a lot of these systems.
Also, usually, software running on embedded systems are small-scale applications, thus profit less of the advantages of C++. Note that I said "usually" - the exception confirms the rule as always :)
Business Accounts
Answer for Membership
by: jkrPosted on 2007-04-18 at 09:29:28ID: 18933007
The main reason is that size does matter. Objects take up more space than plain procedureal C code. Even if that difference is not that big, the aspect of only little RAM compared to dektop systems has a huge impact here.