Some common aspects:
- Compiler option (debug builds usually don't inline, or oyu can tell your compiler to inline regardless of the delcaration)
- suitable calling convention (varargs usually functions aren't inlined)
- suitable for inlining: depends on size of the function, frequency of the funciton, and optimization settings (speed vs. code size). E.g. a huge function may be inlined if it is called just once
- inline call depth and recursion
The 3rd is probably the core of your question, but that's really "compiler specific heuristics" - you need to check the compiler docs, but usualyl they won't give much guarantees. MSDN has some (limited) information for MSVC.
Beyond trivialities (e.g. simple getters and very primitive functions), inlining as such isn't very helpful anymore. The cost of the call instruction has gone down, and branch prediction has greatly improved.
The great opportunity for inlining is removing code paths that the compiler knows won't be taken - as an extreme example:
inline int Foo(bool refresh = false)
{
if (refresh)
{
// ...extensive code to update m_foo
}
return m_foo;
}
A good compiler would inline Foo(false)
, but not Foo(true)
.
With Link Time Code Generation, Foo
could reside in a .cpp (without a inline
declararion), and Foo(false)
would still be inlined, so again inline has only marginal effects here.
To summarize: There are few scenarios where you should attempt to take manual control of inlining by placing (or omitting) inline statements.