It seems indeed counter-intuitive that an inline function has "external linkage" in C++ lingo; after all, the function symbol (its name) is not exported at all in the resulting object file — indeed, there often will not be any function but just inlined code! —, and therefore cannot be linked against, as opposed to the result of external linkage for normal variables and functions.
There is an IBM article which discusses the consequences of inline functions having external linkage, and it agrees with the cppreference page. In short,
- The function has the same address in different translation units (this may matter if you compare function pointers);
- type declarations within the inline function are the same in all translation units (this may be logically tied to the next point, see footnote);
- function-local static variables are shared between the functions (this is extremely important for initialization and resource allocation strategies).
I can imagine that the latter point is the main motivation for the external linkage of inline functions. Initialization of function-local static variables is protected against concurrency and performed only once. It is a common and fail-proof pattern for thread-safe resource allocation. The variables must be shared for that.1 It would be sad to give that up; in particular, one-line functions which return a resource which are prime candidates for inlining. If they could not guarantee that the resource is initialized one would have to choose between the two:
inline FILE *logfile()
{
static FILE *fp = openLogfile(); // done once, thread-safe
return fp; // all subsequent calls simply return fp.
}
External linkage guarantees that all calls of this inline function, across translation units, will return the same file pointer.
1 The "same type" provision may be related to that; imagine that an inline function defines a static custom sentinel class object with a resource handle that is responsible for freeing a resource.
