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