Subject: Re: [boost] Is there a special reason to use inline before template functions?
From: Jonathan Brannan (kickace_at_[hidden])
Date: 2008-12-09 09:15:51
On 12/8/08, Brian Ravnsgaard Riis <brian_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Michael Marcin wrote:
>> Thomas Klimpel wrote:
>>> I would expect that current compilers know better when inlining a
>>> function provides a benefit than the programmer.
>> They don't.
> This is really sorta off-topic here, but I find that statement hard to
> believe. Can you in any way substantiate that argument? I personally
> *never* use the keyword inline, since the compiler is free to ignore it,
> and may choose to inline functions I have not declared inline.
> What little I do know about compiler internals would lead me to believe
> that they could - and should - indeed know better than the programmer
> when it makes sense to inline a function.
> To complicate matters further, inlining a given function may make sense
> in certain contexts but not others. I believe Herb Sutter has given the
> subject thorough treatment some years gone. Nothing I have experienced
> has caused me to doubt his words in this matter.
The compiler is free to not inline the contents of the function, but
inline also changes the resolution rules. It causes it to be defined
in each compliation unit (in C you would use static to change the
resolution rules between objects). If you define a function in a
header, it should be inlined to avoid linker errors. If you have
function defined in a class defination, it is inlined even without the
We use inlining in release builds were things like getters (and, of
course, templates class member functions that are defined outside of
class declaration) are included in from header files and in debug
build get built into the object files. It allows for more than just
inlining the body of the function, if you have chains of getters that
are defined to where the compiler can see them, they get to all be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk