On 12/8/08, Brian Ravnsgaard Riis <brian@ravnsgaard.net> 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 keyword. 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 optimized away.