TITLE: linkage of inline functions

(Newsgroups: comp.std.c++)

[ This is a discussion over the "scope" of inline functions. It used to
  be that inline functions had static linkage (ie, they were private to
  any given translation unit). Apparently there has been a change in
  this. -adc ]
  

CLAMAGE: clamage@Eng.Sun.COM (Steve Clamage)

This latest change [giving all inline functions external linkage]
removes a special case from the language. Inline functions have no
special semantics. I think the silent change in meaning of "inline"
functions is unlikely to invalidate many, if any, existing
programs. It seems unlikely that the correctness of a program would
depend on having more than one instantiation of an inline function.


KANZE: kanze@gabi-soft.fr (J. Kanze)

I've been wondering about this.  I'm not too worried about the number of
instances of a single function.  I am concerned about the case where I
have two different inline functions, in two different translation units.
What happens if they have the same signature (name and parameters)?  Is
this just a violation of the one-definition rule, which means that a
working program suddenly has undefined behavior (which most compilers do
not currently detect, although they could and should)?  Or is there some
trick with namespaces (and the unnamed namespace) which means that this
should work?

CLAMAGE: clamage@pacific-88.eng.sun.com (Steve Clamage), 20 Aug 96

If in existing code you have two inline functions, not in any namespace,
in different translation units with the same signature but different
definitions (bodies), the code is valid under the old rules. Functions
with static linkage in different translation units are always unique.

Of course, different functions with the same signature is not such a
great idea, and could cause some confusion even under the old rules. You
might decide to put one or both of them in a header at a later time,
leading to conflicts.

Under the new rules, the original code would become undefined, since it
would violate the one-definition rule: Two definitions for an external
function. It seems likely to me that the error would be detected at
link time, but maybe not. (Detection is not required.)

A workaround would be to put one or both in different namespaces
(or both in the unnamed namespace) in the different translation units.
The unnamed namespace is the suggested replacement for static linkage
anyway. Any compiler which supports the new linkage rules for inline
functions will also support namespaces.