Automatic function inlining and static functions
-O3 levels of optimization, or when
--autoinline is specified, the compiler can automatically inline functions if it is practical and possible to do so, even if the functions are not declared as
This works best for static functions, because if all use of a static function can be
inlined, no out-of-line copy is required. Unless a function is explicitly declared as
__inline), the compiler has to
retain the out-of-line version of it in the object file in case it is called from some other
It is best to mark all non-inline functions as static if they are not used outside the
translation unit where they are defined (a translation unit being the preprocessed output of
a source file together with all of the headers and source files included as a result of the
#include directive). Typically, you do not want to place definitions of
non-inline functions in header files.
If you fail to declare functions that are never called from outside a module as
static, code can be adversely affected. In particular, you
A larger code size, because out-of-line versions of functions are retained in the image.
When a function is automatically inlined, both the in-line version and an out-of-line version of the function might end up in the final image, unless the function is declared as
static. This might increase code size.
An unnecessarily complicated debug view, because there are both inline versions and out-of-line versions of functions to display.
Retaining both inline and out-of-line copies of a function in code can sometimes be confusing when setting breakpoints or single-stepping in a debug view. The debugger has to display both in-line and out-of-line versions in its interleaved source view so that you can see what is happening when stepping through either the in-line or out-of-line version.
Because of these problems, declare non-inline functions as
when you are sure that they can never be called from another module.