inline constructor and destructor

[Tim]

Dear All,

I am confused about when I should use inline constructors and
destructors. I have test some simple cases, seems the inline ones are
faster. Why some book suggest not use/overuse the inline constructors
and destructors?

Thanks,

Tim

 

[Victor Bazarov]

I am confused about when I should use inline constructors and
destructors.

In most cases if your function does not need to use any type that
depends on this type to be complete, and the function seems to fit
in a few lines of code, there is nothing to stop you from defining
it in the class definition.

I have test some simple cases, seems the inline ones are
faster.

Good. Keep them.

Why some book suggest not use/overuse the inline constructors
and destructors?

What book?

V

 

[duane hebert]

Dear All,

I am confused about when I should use inline constructors and
destructors. I have test some simple cases, seems the inline ones are
faster. Why some book suggest not use/overuse the inline constructors
and destructors?

Maybe some insight here:
http://www.codeguru.com/cpp/tic/tic0162.shtml

 

[James Kanze]

I am confused about when I should use inline constructors and
destructors. I have test some simple cases, seems the inline ones are
faster. Why some book suggest not use/overuse the inline constructors
and destructors?

The simple answer is that you should never inline, or only when
the profiler shows that you must. Inlining significantly
increases coupling, and should be avoided unless absolutely
necessary.

A more complex answer would take into account cases where the
coupling is present anyway, e.g. templates (in the lamentable
absense of export), and "local" classes, only used in the
implementation of some exported class. There are also some
cases where it may be desirable to use inline in order to
completely avoid having a source file/object file---I generally
inline the virtual destructor of an interface, as 1) by
definition, it will be empty, and never change, and 2) it seems
a real waste to require a .cc file and to generate an object
file for a single, empty function.

Also, some modern compilers (not many, yet) are better at
deciding what to inline than you are, and many are quite capable
of inlining code which hasn't been declared inline, even if the
function definition isn't in the same compilation unit. Long
term, I would expect this to be the general case, since the
decision to inline or not really should depend on the frequency
the call site is executed, not on which function is being
called. (In this regard, the way C handles inline is actually
superior to what C++ does, although it is overly complex and
awkward to use otherwise.)

If a book emphasizes not inlining constructors and destructors,
it is probably because in these cases, even apparently trivial
or empty functions often contain a lot of implicit, compiler
generated code, and can end up quite large, and result in
significant code bloat. (This is probably less of an issue than
it used to be, but it is still worth considering; even if code
bloat typically won't prevent the code from fitting in memory,
it will reduce locality, and increase cache misses, and possibly
even cause more page faults.)

 

[Ian Collins]

If a book emphasizes not inlining constructors and destructors,
it is probably because in these cases, even apparently trivial
or empty functions often contain a lot of implicit, compiler
generated code, and can end up quite large, and result in
significant code bloat. (This is probably less of an issue than
it used to be, but it is still worth considering; even if code
bloat typically won't prevent the code from fitting in memory,
it will reduce locality, and increase cache misses, and possibly
even cause more page faults.)

While I agree with most of this (and everything I snipped), also note
that compiler/linker combinations are also getting good at eliminating
duplicated code, so an inline constructor will only appear once in the
final executable.

 

[James Kanze]

James Kanze wrote:

<good advice snipped>

While I agree with most of this (and everything I snipped), also note
that compiler/linker combinations are also getting good at eliminating
duplicated code, so an inline constructor will only appear once in the
final executable.

If they're not inlined. The whole point of inlining is that the
code will appear in place of the call.

Globally, of course, this is much less of a consideration than
it used to be. Almost all of the coding guidelines I saw in the
1990's forbid inline for constructors and destructors, for this
reason. More recent ones don't, except in so far as they forbid
inline in general. (My own rule would be to forbid inline in an
"exported" file, i.e. a header which will be used by the
client. With more tolerance in the case of templates.)

 

[Ian Collins]

If they're not inlined. The whole point of inlining is that the
code will appear in place of the call.

True, but even if they are, some compilers can factor out repeated code
as a space optimisation.