Inlining is the programmers personal optimizer in C++. It is theoretically a great idea: Inlined functions act and look like functions, but avoid the actual function call; they act like macros to the C programmer, but are not compiler directives; and, they help out the optimizers by eliminating function calls.
Unfortunately, inlining is much more complicated than it seems. Meyers  in his Rule 33 outlines many problems of inlining - some of which actually create more code and longer running programs that those without inlining.
However, the most important negative impact of inline code is that most debuggers cannot cope with inlining (How do you set a breakpoint at a function that isn't there). This single fact has lead Meyers  to a strategy which determines which functions should be inlined and which should not :Don't inline anything, or at least limit your inlining to those functions that are truly trivial.
In general, inlines should be used judiciously and I recommend that only the most elementary functions (like the access functions in the Vector class) should be inlined. After the code executes and is debugged, you can use a profiler to determine where the bottlenecks exist and inline certain crucial routines to improve the operation in these areas. But only do this after the code is working!
This document maintained by Ken Joy.
Comments to the author : firstname.lastname@example.org
All contents copyright (c) 1998
Computer Science Department, University of California, Davis
All rights reserved.