pure virttual function

[Alf P. Steinbach]

* Alf P. Steinbach:

struct Oops
{
Oops() { g(); } // <-- Call of pure virtual function
virtual void g() = 0;
};

void Oops::g() {}

For any quality compiler you're guaranteed that the code fails to
compile or else that the call g() is implemented as a virtual call (then
resulting in a call of a function that issues a run-time diagnostic), in
spite of the dynamic type of the object being known.

Except MSVC 7.1... :-(

g++ refuses to compile the code, Comeau warns, MSVC 7.1 happily compiles
it with no diagnostic (!) and calls the Oops::g() implementation.

Did I just say that MSVC 7.1 is not a quality compiler? Seems so.
Since I've maintained the opposite on numerous occasions I have hereby
contradicted myself -- what would life be without contradictions?

 

[Andrey Tarasevich]

It means that the compiler may choose to implement the call below,

struct Foo { virtual void bar() {} };

int main() { Foo().bar(); }

as a virtual call or as a statically bound call, at its discretion, and
the only way you'll ever know would be by inspecting the machine code.

Well, the only distinction between the two methods of invoking a function I was
trying to describe in my message is the distinction explicitly mentioned in the
language specification: what I referred to as "dynamic call" is a call that is
resolved in accordance with the _dynamic_ type of the object expression (which
is the standard terminology), while "static calls" are resolved in accordance
with static type of the object expression. This distinction does exist at
conceptual level, i.e. it is specified in the language standard and it does
apply to point (2), as it applies to all other points.

Since you mention the machine code (and taking into account the example above),
you apparently are talking about significantly more lower-level details relevant
to more-or-less "traditional" implementations of the virtual call mechanism. I,
on the other hand, was not trying to get such low-level details involved.