Editing Inline function (section)

==Problems==
{{see also|Inline expansion#Effect on performance}}

Besides the problems with inline expansion in general (see {{Section link|Inline expansion#Effect on performance}}), <code>inline</code> functions as a language feature may not be as valuable as they appear, for a number of reasons:
* Often, a compiler is in a better position than a human to decide whether a particular function should be inlined. Sometimes the compiler may not be able to inline as many functions as the programmer indicates.
* An important point to note is that the code (of the <code>inline</code> function) gets exposed to its client (the calling function).
* As functions evolve, they may become suitable for inlining where they were not before, or no longer suitable for inlining where they were before. While inlining or un-inlining a function is easier than converting to and from macros, it still requires extra maintenance which typically yields relatively little benefit.
* Inline functions used in proliferation in native C-based compilation systems can increase compilation time, since the intermediate representation of their bodies is copied into each call site.
* The specification of <code>inline</code> in C99 requires exactly one external definition of the function, if it is used somewhere. If such a definition wasn't provided by the programmer, that can easily lead to linker errors. This can happen with optimization turned off, which typically prevents inlining. Adding the definitions, on the other hand, can cause unreachable code if the programmer does not carefully avoid it, by putting them in a library for linking, using link time optimization, or <code>static inline</code>.
* In C++, it is necessary to define an <code>inline</code> function in every module (translation unit) that uses it, whereas an ordinary function must be defined in only a single module.  Otherwise it would not be possible to compile a single module independently of all other modules.  Depending on the compiler, this may cause each respective object file to contain a copy of the function's code, for each module with some use that could not be inlined.
* In [[embedded software]], oftentimes certain functions need to be placed in certain code sections by use of special compiler instructions such as "pragma" statements.  Sometimes, a function in one memory segment might need to call a function in another memory segment, and if inlining of the called function occurs, then the code of the called function might end up in a segment where it shouldn't be.  For example, high-performance memory segments may be very limited in code space, and if a function belonging in such a space calls another large function that is not meant to be in the high-performance section and the called function gets inappropriately inlined, then this might cause the high-performance memory segment to run out of code space.  For this reason, sometimes it is necessary to ensure that functions do ''not'' become inlined.