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: "Clark Cox" <email@hidden>
- Date: Tue, 5 Dec 2006 16:12:41 -0500
On 12/5/06, Chris Page <email@hidden> 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...
I think it's worth noting that the use of the 'inline' keyword is not
synonymous with putting code in headers.
class foo
{
void member_function() { }
// implicitly 'inline'; in fact, IIRC, the inline keyword
// isn't valid here (despite compilers that allow it).
That is simply wrong. The inline keyword is perfectly valid (although
redundant) here.
}
inline void inline_non_member_function() { }
// explicitly 'inline'
void non_member_function() { }
// Default inline behavior, just as with any other function
// in the translation unit.
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.
The compiler does care. If any non-inline function definitions are
included in multiple translation units, then you will cause a copy of
the function to be defined in each of those translation units --
leading to linker errors/warnings.
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.
Yes, there is a guarantee. Unless those definitions are inline, there
will be one copy produced per translation unit. In the case of
'static' these symbols will be internal to each of the translation
units, and will not conflict with each other, but they will not be the
same function (i.e. they will have different addresses). In the case
of an anonymous namespace, they will be different functions with
different names (under the hood), but will be external symbols.
--
Clark S. Cox III
email@hidden
My CV/Resume:
http://homepage.mac.com/clarkcox3/files/Resume.pdf
http://homepage.mac.com/clarkcox3/files/Resume.html
_______________________________________________
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