C++ in embedded systems

I never said C++'s lack of OO purity prevents using it effectively - I said that it was obvious that C++ was not designed to *be* OO, but rather to *add* OO to a procedural base language.

Absolutely. The very issue Andras Tantos and I were discussing previously: parametric dispatch on object parameters.

Anytime you have a base class pointer (or reference) and must pass the object to a function based on the runtime type, you have to do it manually. Code such as the following (abbreviated) cannot select the right overload of F() based on the runtime type of the object and the call to G() won't compile.

: class A; class B : public A; void F( A &a ); void F( B &b); void G( B &b ); : A *pA = new B; F( *pA ); // calls F(A) not F(B) G( *pA ); // error ... argument is not a reference to B :

Whenever you need code such as this, you must test for the actual runtime type, construct a new pointer or reference with the appropriate static type and manually dispatch the call - in effect manually doing everything objects are supposed to do automatically.

I'm sure if I looked back at C++ code I've written over the years I can find other really annoying examples. The parametric dispatch issue just happened to be at hand.

George

This is one of those misconceptions I was talking about. This is not OOP at all. This is just function overloading. Which has nothing to do with OOP. What you really want to do is use polymorphism.

--jc

You're missing the point ...

It is not a misconception about OO at all ... it is a case where objects in C++ don't behave as objects, but instead behave as raw data, forcing the programmer to explicitly code the desired object polymorphic behavior.

I know the difference between object polymorphism and parametric polymorphism. My point is that C++ purports to provide both and manages to accomplish neither when the two concepts are used simultaneously.

George

Do you have a source where it states that function overloading is supposed to provide polymorphic behavior?

Object polymorphism implies inheretance and member functions, but your example contain neither. Parametric polymorphism implies templates, but your example doesn't use this either. Your assertions would be a lot more powerful, if they were backed up with concrete examples that actually contain the semantics you're discussing.

--jc

Polymorphism is the quality of being able to assume different forms.

Do you know of a reason to allow differently parametered functions to have the same name apart from wanting the name to mean different things?

I'm unclear as to whether you mean "template" mathematically as a generic specification of function or whether you mean a C++ template. I'm going to assume the mathematical usage as the other makes very little sense in this discussion.

WRT programming models, object polymorphism is just a restrictive, special case of parametric polymorphism obfuscated by syntactic sugar. I'm not going to debate the merits of reasoning with the "special" object model vs. the general functional one - we can continue that discussion in comp.lang.whatever ... it's several parsecs further OT than we already are now.

ISO/IEC 14882 sections 3 [basics] and 10 [classes] state that name lookup may associate more than one declaration with a name if the name is found to be a function, and the set of declarations forms a set of overloaded functions. Section 13 [overloading] spells out the resolution of overloaded functions. A function containing an implicit object parameter, ie. a member function, is determined statically at compile time from the (positional) static types of the function parameters excluding the implicit object parameter. The actual function is determined at run time by the actual type of the implicit object parameter.

C++ implements a half baked scheme of statically resolved parametric polymorphism which disallows most uses of object parameters and uses a special case to allow one particular syntactic form to be handled at run time while disallowing all other equivalent syntactic forms.

In simple terms: C++ implements object polymorphism as lobotimized parametric polymorphism.

You asked me in what situation(s) C++'s distinction between objects and other data types mattered. I answered that question and provided a simple example. The issue you missed entirely is this:

"Objects in C++ don't always behave as objects."

George

I guess I wasn't clear in my response to this assertion. So let me state it explicitly.

"No one cares! Most people can still do OOP in C++ just fine."

--jc

Well, your first statement is obviously false. As to the second, I defer to one wiser than myself, who once wrote: "It is clearly possible to write good code in C++. It's just that no one does."

Regards,

-=Dave

I guess I should have chosen better words.

Yes, I totally agree. Considering this sub-thread is based on misconceptions of C++, this observation would be implied...

--jc

To know that "no one does" needs omniscience, not mere wisdom. So your source was not a particularly wise person, then! In fact, I've seen quite a lot of "good" C++ code, though there's a lot more bad code about - in all languages. C++ is certainly not foolproof; the answer is not to put it in the hands of fools (or, at least not to accept the output of such people as viable code).

Peter.