On Sep 13, 10:13 am, Ian Collins <ian-n...@hotmail.comwrote:
James Kanze wrote:
<good advice snipped>
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.
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.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
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
