* (e-mail address removed):
Some of your terminology seems to be garbled. I take it you
mean that an 'inline' virtual routine will not be called
virtually. Well, that's incorrect: a virtual routine is always
called virtually or, with respect to possible optimizations,
*as if* it had been called virtually.
'inline' does not affect that.
Inline (by definition in the standard) has NO effect on the
semantics of a function. On the other hand, a virtual function
will not be called virtually if there is an explicit qualifier,
e.g. MyClass::f().
More generally, I'm not sure what "to be called virtually"
means. I've never seen the expression in any serious technical
literature, and the "native English" meaning would be that the
function isn't called "really", only virtually. But that
doesn't make sense here, and as you say, his terminology is
rather garbled, so I'm supposing, as you apparently did, that he
means that the dynamic type of the object will determine the
actual function called, rather than the static type. In which
case, of course: if a virtual function is called without an
explicit qualifier, the function called is always determined
according to the dynamic type of the object. The only
exceptions (maybe) are the compiler generated calls to the
constructors and destructors of base classes, from the
constructor or destructor of the derived class.
Of course, how the compiler decides which function to call is
its business, as long as it calls the right one. Most compilers
use the vptr/vtbl mechanism to call a virtual function, when
they don't know what the actual most derived type will be, and
use exactly the same mechanism they use to call a non-virtual
function if they do know. (I know you know this, but somehow, I
have the impression that the original poster doesn't.) And most
compilers cannot "inline" a function if they don't know which
function is actually going to be called (although I've heard of
at least one compiler that can do this, in certain special
cases).
Nothing is strictly "necessary".
It depends. If you want the destructor of the base class to be
virtual, it's necessary to declare it; the compiler generated
default won't be virtual.
It's actually an interesting example, since if the base class is
abstract, the "virtual" destructor will never be called via the
virtual function mechanism (since this will always resolve to
the destructor of the most derived class); it will, however, be
called directly (as if qualified) by the destructors of the
derived classes.
The second part isn't. In C++, an inline function is a
function.
The guaranteed effect of 'inline', or equivalently for a
member routine, defining a member routine in the class
definition, is to allow this definition to occur in more than
one compilation unit.
And to require this definition to be present in all compilation
units which use the function.
Additionally, by having the source code available (i.e. the
source code is available "inline" in e.g. a header file), this
allows some optimizations such as machine code inlining
without using costly global program optimization.
There's also a clear statement in the standard concerning
intent. A compiler should make a greater effort to generate the
code inline (suppressing the function call) if the function is
declared inline. From a QoI point of view, it's pretty much
like register: the compiler should respect it unless it can
actually do a better job at optimizing. The only difference
being that this is the case for register, for almost all
compilers, and it is not the case for inline, except for a very
few compilers (but the number is probably growing).