By inlining your code where it is needed, your program will spend less time in the function call and return parts. It is supposed to make your code go faster, even as it goes larger (see below). Inlining trivial accessors could be an example of effective inlining.
By marking it as inline, you can put a function definition in a header file (i.e. it can be included in multiple compilation unit, without the linker complaining)
Disadvantages
It can make your code larger (i.e. if you use inline for non-trivial functions). As such, it could provoke paging and defeat optimizations from the compiler.
It slightly breaks your encapsulation because it exposes the internal of your object processing (but then, every “private” member would, too). This means you must not use inlining in a PImpl pattern.
It slightly breaks your encapsulation 2: C++ inlining is resolved at compile time. Which means that should you change the code of the inlined function, you would need to recompile all the code using it to be sure it will be updated (for the same reason, I avoid default values for function parameters)
When used in a header, it makes your header file larger, and thus, will dilute interesting informations (like the list of a class methods) with code the user don’t care about (this is the reason that I declare inlined functions inside a class, but will define it in an header after the class body, and never inside the class body).
Inlining Magic
The compiler may or may not inline the functions you marked as inline; it may also decide to inline functions not marked as inline at compilation or linking time.
Inline works like a copy/paste controlled by the compiler, which is quite different from a pre-processor macro: The macro will be forcibly inlined, will pollute all the namespaces and code, won’t be easily debuggable, and will be done even if the compiler would have ruled it as inefficient.
Every method of a class defined inside the body of the class itself is considered as “inlined” (even if the compiler can still decide to not inline it
Virtual methods are not supposed to be inlinable. Still, sometimes, when the compiler can know for sure the type of the object (i.e. the object was declared and constructed inside the same function body), even a virtual function will be inlined because the compiler knows exactly the type of the object.
Template methods/functions are not always inlined (their presence in an header will not make them automatically inline).
The next step after “inline” is template metaprograming . I.e. By “inlining” your code at compile time, sometimes, the compiler can deduce the final result of a function… So a complex algorithm can sometimes be reduced to a kind of return 42 ; statement. This is for me extreme inlining. It happens rarely in real life, it makes compilation time longer, will not bloat your code, and will make your code faster. But like the grail, don’t try to apply it everywhere because most processing cannot be resolved this way… Still, this is cool anyway… :-p
