Re: inlining virtual functions
Martin Bonner wrote:
Alf P. Steinbach wrote:
* gelbeiche:
in "More Effective C++" Scott Meyers point out that inlining virtual
functions should be avoided.
However in real code I see that small virtual functions are inlined
quite frequently.
Should this cases considered as small bugs or are there situations
where inlining virtual functions is still reasonable(perhaps due to
clever compiler) ?
It's valid to inline virtual functions.
I'm not sure what arguments Scott Meyers use against inlining, but
whether a function is virtual or not has nothing whatsoever to do with
whether inlining is a good idea or not, in a specific case (perhaps
you're sitting on an old edition of the book, check the errata?).
Whether to inline or not is an engineering decision based on e.g.
clarity of code, coding time, build time, coding guidelines, hiding
source code from the client code programmer, or the opposite, ensuring
self-documenting code, and so on; it can also be more or less arbitrary.
There are two things going on here called "inlining". One is adding
the "inline" keyword to a function definition (or implicitly declaring
a member function as inline by defining it in the class body). The
other is the compiler replacing a call to a function with the
instructions that constitute the body of the function.
I think that part of Alf's point is that this second meaning
isn't always relevant; that it probably is never relevant in the
initial decision. (It is relevant, of course, if you are
inlining as a result of profiler output, because the program
wasn't fast enough. But in the end, I suspect that that's a
rather rare case.)
The most important difference which inlining makes is whether
the function definition goes in a header file, or the source.
If you want the function definition in the header file, you
inline the function, regardless of whether it is virtual or not.
If you want the function definition in a source file, you don't
inline the function, again, regardless of whether it is virtual
or not. And whether you want the function definition in the
header or in a source file is an engineering decision.
These two things are in principle unrelated. A compiler may inline a
function that is not defined with the "inline" keyword, and may
generate calls to functions define with the "inline" keyword. In
practise of course, compilers are more likely to inline functions that
are defined with the "inline" keyword, and very unlikely to inline
functions defined in a difference translation unit (although in
principle a whole-program optimizer could).
One reason for wanting to put the function definition in the
header might be to facilitate this optimization on the part of
the compiler. It's certainly not the only one.
It is theoretically possible for a compiler to generate inline
code for a virtual function, if it knows the actual dynamic
type of the object. (Perhaps because the virtual function is
being invoked on an actual object, rather than a pointer or
reference). In practise, this optimization is rare.
It depends on the class. I've found it occurs rather frequently
when I'm using the template pattern, or mixins.
Adding the "inline" keyword to a function definition means that the
function has to be defined in a header file, rather than in a .cpp
file. This is bad because it increases coupling between translation
units.
And we're back to where we started. *IF* this coupling is bad
(and it often is), then you don't declare the function inline.
Whether it is virtual or not has nothing to do with it.
On the other hand, there are cases where the coupling issue is
irrelevant, and you want the definition in the header.
Typically, you do this in order to completely avoid having a
source and an object file, but I'm sure that there are other
reasons as well. In this case, you declare the function inline,
whether it is virtual or not.
Interestingly, the largest single use I make of inline is for
virtual destructors -- if I'm defining an interface, it seems
rather silly to have to create a source file for a single, empty
function (which will in fact never be called dynamically
anyway).
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]