I have a number of small functions which are defined in a .h
file. It is a small project (now) and I want to avoid the pain of having declarations and definitions separate, because they change all the time. To avoid multiply-defined symbols, I can either have them static
or inline
. What should be preferred and why?
I know it is in general bad practice to define functions in headers. You don't have to mention that in answers, this question is meant technically.
Typically, static functions are functions needed in only one file. They are declared static to make that explicit by limiting their visibility. Declaring them in a header therefore is somewhat antithetical.
The definition of an inline function doesn't have to be in a header file but, because of the one definition rule (ODR) for inline functions, an identical definition for the function must exist in every translation unit that uses it. The easiest way to achieve this is by putting the definition in a header file.
The answer to the above is yes. header files are simply files in which you can declare your own functions that you can use in your main program or these can be used while writing large C programs. NOTE:Header files generally contain definitions of data types, function prototypes and C preprocessor commands.
A static inline function is, in practice, likely (but not certain) to be inlined by some good optimizing compiler (e.g. by GCC when it is given -O2 ) at most of its call sites. It is defined in a header file, because it then could be inlined at most call sites (perhaps all of them).
I'd use static inline
, but static
would work just as well.
extern
and extern inline
are out because you'd get multiple external definitions if the header is included in more than one translation unit, so you need to consider static
, static inline
and inline
specification.
Heptic correctly states in his answer that most compilers consider functions for inlining regardless of whether inline
is specified or not, ie the main impact of inline
is its effect on linkage.
However, static
definitions have internal linkage, so there's not much difference between static
and static inline
; I prefer static inline
for function definitions in header files for purely stylistic reasons (rule of thumb: header files should only contain extern
declarations, static const
variable definitions and static inline
function definitions).
inline
without static
or extern
results in an inline definition, which the standard states (C99 6.7.4, §6)
provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition.
ie inline definitions should always be accompanied by external definitions, which is not what you're looking for.
Some more information about the subtleties of C99 inline semantics can be found in this answer, on the Clang homepage and the C99 Rationale (PDF).
Keep in mind that GCC will only use C99 semantics if -std=c99
or -std=gnu99
is present...
Since the question is about C (not C++), inline
means that
extern
(ISO9899-1999, 6.7.4(6), for example an inline
funciton with external linkage must be defined in the same compilation unit, and an inline definition allows an extern
definition elsewhere without an error (which is not necessarily a good thing, because the two functions need not be functionally equivalent, and it is unspecified which one the compiler uses at any time!). The linker implications given by Heptic are required for C++, but not required by C (as far as I can tell). They are necessarily required by the "shall have the same address in all translation units" clause in ISO14882, 7.1.2(4). I am not aware of any similar clause in C99.
However, since the entirely different languages C and C++ usually go through the same C/C++ compiler and linker, it likely works identically for C, anyway.
So... how to answer your question? Use inline
when you feel it's adequate. Be aware of the possible pitfalls of extern
. Otherwise, leave it away and trust the compiler to do it right.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With