Two conundrums are associated with inline functions. The first has to do with maintenance. A function can begin its life as a slim inline function, offering the benefits that are associated with inlining. At a later phase in the lifetime of the system, the function body can be extended to include additional functionality, due to changes in the implementation of its class. Suddenly, inlining can become inefficient or even impossible. Therefore, it is important to reconsider the removal of the inline specifier from functions that are extended. For member functions defined in the class body, the change is more complicated because the function definition has to be moved to a separate source file.
Another problem can arise when inline functions are used in code libraries. It is impossible to maintain binary compatibility if the definition of an inline function changes. In this case, the users must recompile their code to reflect the change. For a non-inline function, the users only need to relink their code, which is considerably less of a burden than a massive recompilation and relink.