Re: C++ inlining and function definitions in headers (was Re: XCode Falls Short - for now)
Re: C++ inlining and function definitions in headers (was Re: XCode Falls Short - for now)
- Subject: Re: C++ inlining and function definitions in headers (was Re: XCode Falls Short - for now)
- From: Thomas Engelmeier <email@hidden>
- Date: Tue, 5 Dec 2006 12:57:58 +0100 (MET)
On 05.12.2006, at 11:10, Chris Page wrote:
On Nov 4, 2006, at 02:42 AM, Thomas Engelmeier wrote:
On 30.10.2006, at 21:18, Dave Camp wrote:
Maybe this explains Windows engineers tendency to put all their C+
+ code in the .h files? Almost every Windows port job I work on
has 50-75% of the C++ source inlined in the .h files. I've never
been able to get an explanation as to why I see this so often...
that's got to put a lot of pressure on the linker to strip out
all the duplicate code generated in each object file.
Apparently you have a different interpretation of the meaning of
the "inline" keyword than I have. I would be highly embarrassed if
the linker strips (duplicated) inlined code - except in some
special conditions...
[...]
Strictly speaking, the compiler doesn't know or care whether any of
the above definitions are in a header or source file, because the
semantics are that headers are first concatenated into the
translation unit by the preprocessor and then handed over to the
compiler.
No, strictly speaking not. Anyway, the one definition rule butts in
(i.e. if one wants to have the inlined code in more than one
translation unit it makes sense to put the implementation in the
header file).
Note that just because a function is marked 'inline' (either
implicitly or explicitly) it doesn't guarantee that it will be
inlined or that it won't also generate a non-inlined copy.
Likewise, just because a function isn't marked 'inline' doesn't
mean it won't be, nor does it guarantee that a non-inline copy will
be generated (other factors, such as compiler and linker export
settings play a role here). 'inline' is just a hint to the compiler
about what you would prefer it to do by default.
I know about those limitations ("some special conditions" ;-) -
anyway, unless I explicitely turn inlining off (e.g. for debugging),
I definitely consider a toolchain implementation that uses an
unreasonable amount of function calls for e.g. accessor one line
inlines extremely crappy.
Finally, there is no guarantee one way or the other whether a
'static' function or a function in the anonymous namespace, when
placed in a header, will produce one or multiple copies if it is
#included in more than one translation unit -- that's usually up to
the linker and/or implementation-dependent compiler options.
And IIRC gcc uses the worst case implementation - linker errors when
you do that...
Regards,
Tom_E
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden