Subject: Re: [boost] Is there a special reason to use inline before template functions?
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-12-09 11:23:56
Brian Ravnsgaard Riis 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.
The compiler can know a lot but it can't know how often code is called
when calling the code is the result of data or user input.
> 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.
Inlining is a low level optimization and like all such optimizations
they should only be done after the correct algorithms, abstractions, and
representations are in place with the aid of profiling.
That being said I worked on a embedded project that needed to render 3d
in software in realtime. We made heavy use of boost, templates, classes,
and metaprogramming. In the rendering code especially controlling which
functions were expanded inline and which were function calls was the
difference between having a product which could ship and one that was
too slow to pass cert. Luckily we were able to give the compiler enough
information to choose which functions to inline because the language
gives us the tool to do so, the inline keyword.
-- Michael Marcin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk