Re: How C++ programmers think
Posted: Dec 29, 2005 9:28 AM
> C++ Programmers have to decide to make methods "virtual"
> in order to allow OOP practices. They know that doing so
> has a performance penalty
Not necessarily. Whether or not a call is resolved at compile-time or run-time is an implementation detail, but if not enough information (for that specific compiler) is available at compile-time to make the decision, then it will be resolved at run-time. To take en example:
void f(Derived d)
Here, even if g() is defined to be virtual, the call will be resolved at compile-time, and g() will be called non-virtually, possibly inlined. That's because the compiler knows the type of "d".
However, if "d" is a pointer or reference to Base, and the compiler can't otherwise figure out what its "dynamic type" (the type of the object being referenced or pointed at) is, then the call will be resolved dynamically:
void f(Derived &d)
In the first example, it might even elide the vtable-pointer in the object in f(), as it doesn't need it to make the call, hence the virtual function declaration not having any size-implications of the object, either. Again, it is implementation-defined whether or not that happens.
> C++ fakes classes by creating a
> structure that holds all the data, and then defining all
> methods as functions that take that structure as a hidden
That's a puzzling way of putting it, and strictly speaking, wrong. What you describe is _one_ possible way of implementing classes in C++ (as well as other languages with a similar OO-model, like Java), but not the only one. It's, however, probably more or less the only method being used, as it works well. However, my point is that nowhere in the C++ standard does it specify how classes and virtual functions are implemented.
Secondly, could you explain what you mean by this implementation method being used to "fake classes"? In this case, how do you define "real" classes, and can you provide any "authority" as to what should be the proper definition of "class"? (The earliest use of classes, is, from what I've hard, the Simula language in the 60's. Both Smalltalk and C++ "inherited" the notion of classes and polymorphism from Simula.)
> The fact that CDiggins has defined the interfaces concept
> as something resolved at compile time means that the
> methods in question would be compiled down to name-mangled
> function without a pointer involved. No speed hit.
Just as a compiler can do if it has enough knowledge to resolve the call to a virtual function at compile-time, as shown above.
> The sticky problem is making sure enough information is
> around at compile time to resolve the interface question.
Indeed, and you may not even have that information at that time. However, a design that dispatches at compile-time when it can, and at run-time otherwise, and doesn't require inheritance from a common base class or interface, is an interesting idea, and would nicely fuse a mechanism like C++ templates and inheritance-based polymorphism (inclusion polymorphism), giving the "duck typing" of templates at run-time, without requiring dynamically typed variables (as in script languages). As I understood from an earlier posting by Christopher in another thread, Heron either had, or might have such a feature.