which object orient language is most suitable for embedded programming?

That agrees with my understanding as well. Some of the discussions here seem to be more about object based programming rather than object oriented programming. Classically at least, OOP requires encapsulation, inheritance and polymorphism.

That does not, however, require OOP or even Object Oriented Design (OOD).

I does seem easier from what I've seen to do bad work with C++ than with a lot of other languages. It seems to hand out much more rope with which to hang yourself.

Robert

In general there is nothing extra needed in C++ startup apart from the static constructors Peter mentioned. If you don't use statically constructed objects, the code required to do so should not be linked in. In a compiler I worked on, the startup code for C and C++ was identical - calls to initialization routines for features that aren't used are automatically removed. That is how things should be.

Wilco

You're dealing with C++, which, to be blunt, is a really crap implementaion of OO principles, for exactly the reasons you mention (amongst others).

Steve

Sorry, Chuck, I sincerely thought you were being funny.

Perhaps I've missed why you consider this example to be OO. Forgive me if so.

Steve

ISTM that when relevant details about costs and benefits of an embedded project are not known, it is not possible to make statements like this whether it is worth the effort or not. IMHO in the embedded world there is no such things as one size fits all.

Rob

I've seen a fair amount of that, including "experts" writing C++ code that broke just about every compiler they tried to compile it on. However high quality code is code that everybody can trivially understand while they casually read it. Using 10 layers of multiple inherited templated virtualised classes is only suitable for obfuscated coding contests.

My take is that C++ is great when used as a "better C". C has a huge amount of shortcomings, and C++ provides new ways of doing the same things as in C, just as efficiently, but in a easier to understand syntax. Simple inline member functions allow zero overhead access to members while providing extra features, such as the possibility of checking accesses at a later point or hiding complex low level details. Using simple classes also reduces the need for global variables (which people writing C seem to insist on). Some minimal inheritance or template can be used to create a generic list class etc.

Things go wrong when people go overboard on the "everything is an object" idea and inherit everything from virtual base classes to provide maximum information hiding (and maximum uncertainty over how it actually works as well as minimum performance). Before you know it, you've lost control over your own code as nobody can understand anymore exactly what happens.

In my experience even C++ compiler experts frequently disagree over how certain things should work - and it's no surprise that even today few compilers implement all of C++ correctly (especially templates). However if you take the middle road C++ is a good improvement over C.

Wilco

Because there is a single entity that lives in the users data space, pointed to by the value returned from stkcreate. There are five operations defined that can be performed on that entity. The internal structure of the entity is completely disassociated from anything else, and can be modified or implemented freely. There is no need or reason for the user to know, or be able to know, anything whatsoever about the contents of a stkobj; he only has access to a pointer to it. The code that does the implementation can be fully reentrant, and thus one copy can be used to implement multiple stacks.

I consider that stack to satisfy the usual definitions of an OO object.

s = stkcreate(SIZE); while (something) { ... if (!stkfull(s)) stkpush(s, whatever); ... if (!stkempty(s)) whatever = stkpop(s); ... } stkkill(s);

and a little generalization with auxiliary functions can make the type of items pushed and popped independent, requiring only modification to stkcreate. See the hashlib implementation to which I referred earlier. Note that functions called between stkcreate and stkkill can use the same stack.

It's sometimes hard to get a straight answer out of this group, but then there are a plethora of definitions of the rather vague term "embedded" and a fairly large bias against object oriented programming languages.

In my experience, when a language is used that supports various OO concepts, C++ is the most common. The reason for this is that C++ , like C supports system level programming, and can be quite efficient in terms of the generated code.

However, like any good tool, OO can be used for evil ;-)

Many techniques that pass for OO in GUI land are rarely applicable in systems that must execute indefinetly without failure.

Looks like a non-polymorphic class implemented in C no?

But *why* for example would you implement a "vtable" by hand when you can have the compiler do it for you? The language is a tool. If you are going to use an OO technique, then it is more efficient and readable to use an OO tool that supports that technique.

You're confusing object with "abstract data type". You have an ADT here. It's true that it contains nothing anti-OO, but it's not object oriented in any distinctive way. This was the gist of my question to Paul Taylor also, as to whether he was clear on the distinction. OO is much more than just atomic abstract data types.

If C++ were the measure of OO, then OO would deserve most of Steve's criticisms. I think Steve's comments are seriously clouded by him equating it with C++. One of the worst things about C++ (which has been the mainstay of my work for nearly 20 years now), is its mixed and muddled terminology. Just how many different meanings should be attached to words like "static", "virtual"? That makes people think that OO itself is unclear, when in fact it doesn't need to be. Look at Bertrand Meyer's book "Object Oriented Software Construction" if you want a clear and unambiguous terminology to use. My copy's at work; perhaps I'll summarize his definitions here on Monday.

Clifford Heath.

I think it's a matter of nomenclature. In place of a namespace, I use the prefix 'stk'. In place of s.push(x) I use stkpush(s, x). In place of new(s(sz)) I use stkcreate(s, sz). If I want to incorporate a stk in something else (inheritance) I have to write some more code. But I can think about and use a stk in the same way the C++ user does.

If I wish I can complicate the (hidden) definition of a stkobject by incorporating routine pointers, and then write "s->push(x)", and play silly games inside the push code to access the other fields of s by using offsetof. This simply complicates the code and forces the definition of the stk to be exposed and vulnerable.

Whoa. I've been criticising C++. I haven't been criticising OO, which is a methodology that I actively espouse.

Steve

Erm, I don't. Multiple/virtual inheritance is not something I use, or indeed can use, in my C version of OO. Also, I actively avoid runtime overheads - with embedded work in particular, I want as much of the work done at compile time as possible.

Also, from

"Multiple inheritance can cause some confusing situations, so there is some debate over whether or not its benefits outweigh its risks."

Guess which side of the fence I'm on ;).

Agreed. When a good version of C with OO comes along, I'll use it. C++ isn't it.

Steve

Yes, I understood that. Sorry that wasn't clear. And though I agree with you that C++ is sucky, there isn't a better alternative that would have served my purposes. I've also found that there are some cunning ways to use it for embedded programming, though not half as many as a really cleverly designed language would have.

What I'm really trying to say by interjecting here is that I think it's time someone injects a clear definition of the concepts that differentiate OO from abstract data types, and separate the problems of C++ for embedded versus OO for embedded. Judging from Chuck's last response, I failed to communicate the former.

Well, I'm old and crotchety, and don't use OO languages. Maybe after your Monday summary appears I'll be more appreciative of the difference.

Steve at fivetrees wrote:\

I think what this thread has thrown up more than anything is the confusion over the definition of OO design and trying to explain it in terms of C++ facilities puts the cart before the horse. If OO design is a neat way of analysing a problem. it's also not a one size fits all solution, It's just another tool in the box, along with other good stuff like modular programming, state driven design etc. However, OO is fashionable and big business, so don't expect common sense or clarity to prevail.

The problem with C++ is that it constrains whatever OO ideas you may have had because of it's own syntax and constructs, though this is true of any formal language. That is, you are forced into the C++ view of what OO is by the design philosophy of the language itself.

I prefer to think of OO at a higher level. For example, a multitasking OS with message passing interface between tasks is very easy to visualise in an OO way. Same with GUI design. where everything on the screen is an object having attributes of class and value. The chosen language has little to do with this view, which is the way it should be, IMO...

Chris

Well, I use interface inheritance rather extensively, an find it quite useful when creating reusable (in the Open Closed Principle sense) software.

I avoid runtime over-head when it is important to do so, otherwise I use the best tool for the job. However, in my experience, the overhead for single-iheritence vtables in terms of both execution time and code space is minimal. There will always be a place for hand optimization for critical paths and tight real-time constraints, but that is not always a critical factor. As always ... it depends.

Multiple inheritance has its problems, due to implementation issues. It is a tool that I rarely use unless I am combining interfaces. However, I usually find that using composition is better than using MI.

But, what brought up MI?

This, along with an experience where modular design was considered inferior to oo design, was where my original question came from.

with methodologies it seems that common sense can go out the window. My advice for simpler embedded stuff, is just to burn those books on oo design methodology, and use modular design with nice clean interfaces and data hiding (C code + static). Do something more productive with your time, like take your kids to the park, (or whatever your posion is).

Reading such books can be a bane to other engineers' lives. Everything down to such simple things as io/leds/on-chip counters, can be oo-designed in a generic way, so that it can be reused. I have had the misfortune to work on a project where this happened. Just toggling an I/O port required untold processor cycles, using the "object that we use to change the state on a port pin". FFS.

Code written in a more generic way is bigger, slower, takes longer to write, works the brain cells harder, and needs more documentation. It's much easier to look at a microcontroller's pwm counter, say, read the data sheet, find out which few registers you need to stick a number into, rather than get the "pwm object that we use", find out that it doesn't quite fit with your requirements (these things are always infinitely configurable), so you need to tweak it, then worry about whether your changes are going to break anything else it's used for.

Although not in any way high-brow or mentally challenging, reusing code also means using ctrl-c and ctrl-v.

Thanks for listening ;-)

Regards,

Paul