Re: pure virttual function
* Andrey Tarasevich:
Alf P. Steinbach wrote:
Static (non-virtual) call method is used when the function is invoked: 1) by a
qualified name, 2) with an actual object (not a pointer or reference) 3) when
base class destructor is implicitly called from derived class destructor.
Accepting this terminology,
If you are referring to the above use of terms "static" and "dynamic", I agree
that they are a bit ambiguous, since similar terms are used elsewhere in the
language, where they mean something completely different. However, this is not
entirely my invention. This terminology is derived directly from the one used in
the FAQ, see
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.2
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.3
point (2) does not apply to a call to a pure
virtual function from a non-static member function of the class (where
you can very easily have UB if that member function is directly or
indirectly called from a constructor of the class),
I'd say that this is more relevant to point (1), i.e. what I referred to as
"call by a qualified name".
No, I mean an unqualified call, like
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.
This does not contradict what you wrote, it just sensibly narrows the
(lacking) definition of "actual object" in point 2, namely, that it does
not include this case, or any case where g() is called unqualified from
a non-static member function of Oops.
and it does not
apply to a call on a named variable of the class, since no such variable
can exist if the class has a pure virtual function;
That would be point (2), yes.
hence it doesn't
seem to apply to anything in this context, and for the case of a call of
function that's not pure virtual, it's an implementation detail that
only affects the efficiency of a call, if anything, so at the C++ level
it doesn't make much sense to say if that call is virtual or not.
I don't understand what exactly you are referring to by the "implementation
detail" part, since I don't see anything in my post that would be an
implementation detail.
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.
So I contend that point 2 is not actually meaningful as description of
what happens in practice, because it doesn't apply in any concrete case
I can think of, and AFAIK it does not describe a requirement by the
standard -- I'd leave it out entirely, because a reader will try to
ascribe some meaning that matters, which would likely be incorrect.
Anyway, my description was not intended to be limited to the particular case of
_pure_ virtual functions. It was supposed to be more generic, with only the last
paragraph of my original message dealing with pure virtual functions in particular.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?