which object orient language is most suitable for embedded programming?

Assembly.

---

• KSI@home KOI8 Net < > The impossible we do immediately. *

• Las Vegas NV, USA < > Miracles require 24-hour notice. *

-- Posted via a free Usenet account from

What are you trying to do? Are you absolutely positively sure that you want to use object orientation?

Object oriented is a *design* technique. You can apply it to any language, though some claim to make it easier...

Chris

What house design is most suitable for people to live in?

Oh, wait! Different people live in different places with different climates, cultures, geography and available building materials! Maybe there is no one design that is best!

And so it is with programming languages...

I tend to gravitate toward C++, and I suspect that most embedded projects that use object-oriented or object-based techniques use C++. But I know that in the 80's and 90's Tektronix used Smalltalk almost exclusively for its instruments, I know that Ada has a strong following in the military and aerospace world, and I know that Java, for all its warts and bumps in an embedded environment, shouldn't be ruled out.

If you're working on a specific project perhaps you should outline some of its requirements (size, cost, speed, real timeliness, etc.) That will get you closer to an answer for your situation.

People may use C++ techniques but the most CPUs sold are 8-bit based, with limited ROM and RAM.

So C++ will not work on most 8-bitCPU based systems. But C++ techniques could be used in the design of such systems.

donald

Nonsense.

The only reason for not using C++ for 8 bitters is that C++ compilers are not always available. However this is changing.

The claims about terrible inefficiency of C++ are the exaggerations. Also, the cases where the size/speed does matter are rear. If it really does matter, then most likely it signifies design level problems.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

MS Project.

JohnSmith->DevelopBellsAndWhistles.Date(06.11.23);

VLV

Well said.

I do OO in C and assembler.

Steve

I disagree. IMO/IME, C++ is just not well suited to embedded work (where by "embedded" I mean small micro, limited memory/speed, and *mostly* a "Thou Shalt Not Crash" degree of robustness).

Fundamentally, it's the runtime aspects of C++ I'm talking about (late binding, use of heap etc etc). I want as much reliance on compile-time determinism as I can muster.

Yes, there are better C++ compilers nowadays. Yes, one can avoid whole swathes of the language. And yes, it can be done. But again, OO is a

And as I've probably mentioned before, I'm not convinced that C++ is a good language. Where by "good" I mean conducive to robust, readable, maintainable designs. One can achieve better module independence (and data hiding) in classic C than in classic C++ (private data/functions in a public prototype? WTF?).

YMMV ;)

Steve

Dr Miro Samek has described some approaches to OO in embedded C:

The good thing about C++ is that you can choose: If you need late binding, you can have it easily (no need to fiddle with ugly function pointers), if you need the speed of direct calls or inline, you can have that, too.

I do my device drivers in C++, because that usually leads to clearer, shorter code and thus, hopefully, fewer errors. Most of it does without any C++ runtime support, just "C with classes and templates".

Sounds like apples vs. oranges to me. Data hiding in C means having functions operating on pointers to opaque structures - but then, users have to allocate them dynamically through one of your function, because they don't know the size. The whole point of exporting the private data in C++ is to allow construction of class objects on the stack, for efficiency.

(But I agree that the C++ syntax is ugly. However, I doubt that the small beautiful language struggling to get out of it is Java or C#.)

Stefan

( ... )

Agreed. Rearside it's all about speed and volume. Frontside pure quality does it all.

The C++ is C with improvements. The good thing about it is if you don't like some of its features, you don't have to use those. Compared to C, the C++ simplifies the development and helps avoiding several kinds of mistakes.

This is true, however you have to put too much reliance on the developer.

I know a company where the C++ is banned. All development has to be done in plain C. The problem they had before is that it is very difficult to understand and maintain the class hierarchy created by an idiot.

One can achieve better module independence (and data hiding) in

This is a different problem. To be perfect, each and every project requires about 3 times more time and money then it can be allocated.

VLV

Two features of C++ can produce a lot of overhead in C++ programs, especially for small systems - exceptions and RTTI. If you can disable them in the compiler (and C++ compilers I have seen let you do that), then the C++ compiler should generate pretty much identical code for a C function compiled as either C or C++. In other words, no overhead. (Of course, if you make use of exceptions, then the overhead can be worth it.)

However, C++ makes it easier to accidentally generate very inefficient code - even easier than C does. C has a few pitfalls for the unwary embedded programmer, such as using "printf" and linking in a (relatively) huge floating point library. C++ has many more - for example, if you add a virtual destructor to your classes, because that's what you learned on your C++ course, your small classes are going to be an order of magnitude bigger and slower on a limited processor.

Writing efficient C++ code for small micros is certainly possible, and I've seen some very neat examples (like an 8-bit integer class for avrgcc that produced better code than an int8, because it avoided int promotions), but you need to know a lot about the compiler, the language, and the target to get efficient code.

Do you really do oo design, or is it really modular design?

I wonder if 'modular' has gone out of the vocabulary of embedded engineers these days, and the more trendy term 'oo' has replaced it.

If so, I'm out of date ;-)

Regards,

Paul.

OO design is perfectly possible in C (or assembler, though it is a little harder). Basically, it boils down to using structs and passing pointers to the structure as the first parameter to your functions (making "this" explicit). Virtual methods are handled by function pointer members of the struct. Lack of namespaces and overloading mean you have to have some sort of naming convention to keep track of your functions.

Yes, you have a lot of pointers. I have come into contact with this sort of thing on a project. The design was object oriented and the code had loads of pointers in it, which I find best to avoid, especially when none of the 'objects' are instantiated more than once, which was the case then.

I was interested in whether when engineers say they do oo design, whether the term oo is being used to describe modular design.

Regards,

Paul.

It's possible, I suppose, but I think that most folk doing oo design actually know how it differs from modular design. My question now is, do you?

I would not describe my usual style of C code as OO, but some code generators I have used (such as Metrowerks code worrier "beans") generate OO C code in this fashion. The code is horrendously inefficient on Freescale's small 8-bit devices, as they have terrible pointer support (I replaced about 1K of ADC bean code with 2 lines of "normal" C), but not entirely a bad way to handle larger projects on cpus with good pointer support. The big advantage of using something like C++ when doing OO programming is that it will avoid pointers when they are not needed - with C OO techniques, you'd either need a lot of horrible macros and inline functions, or very smart program-at-once optimisation to avoid the pointer overhead.

Of course, there is no line to be drawn between OO design and modular design - the terms encompass a range of techniques and is as much to do with how you think when designing the program as particular coding methods.