> What is different? Inline functions can now have external linkage.
> That means that at most one copy will exist in the program. That in
> turn means that anywhere in the program you take the function's
> address, the addresses will compare equal, and that exactly one copy
> of any local static objects will exist in the entire program.

   Would it by any chance also mean that inline functions can be declared
in source (as opposed to header) files?  This would have the advantage of
removing the implementation of inline functions from interfaces.

   Ion
---
  Og upi vsm trsf yjod upi djpiaf jsbr upit jrsf rcszomrf.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

thp@cs.ucr.edu (Tom Payne) writes:

>: clamage@Eng.Sun.COM (Steve Clamage) writes (in comp.lang.c++.moderated):

>: > 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.

>Normally, I think of "external linkage" as meaning that the identifier
>gets an entry in the object file's linkage table(s).  (Of course,
>that's implementation, not semantics.)

Well, yes, that's the point. "External linkage" means that the
same identifier in different translation units refers to the same
object or function. "Internal linkage" means that the same identifier
in different translation units refers to different things.

How the compiler accomplishes external linkage is not specified by
the standard. I would expect a compiler to use the same mechanism
it uses to ensure only one copy of template functions.

> I presume declarations of
>inline functions still include the function's body and must occur in
>each translation that uses the function.

Yes.

>So, what kind of entry, if
>any, should one now expect such declarations generate in the linkage
>table(s)?  If none, then what does it mean to say that inline
>functions have "external linkage"?  What's different now, except that
>some program that used to be legal now violate the one-definition
>rule?

If you perform some operation that requires the compiler (given a
particular implementation) to create an entry in the global symbol
table in the object file, then that is what will happen. Before,
if the inline function had internal linkage, the symbol would not
go in that symbol table (because it did not have external linkage).

If you don't do anything that makes the compiler think it needs to
put the symbol in the table, then maybe it won't. No valid and
portable program could tell, so why do you care? If you are
writing a program to interpret object files, you do care, but
then it will be extremely platform- and compiler-specific anyway.
You have to ask the compiler implementor how it works.

What is different? Inline functions can now have external linkage.
That means that at most one copy will exist in the program. That in
turn means that anywhere in the program you take the function's
address, the addresses will compare equal, and that exactly one copy
of any local static objects will exist in the entire program.

You didn't have those guarantees before, and some of those points
were simply unspecified in the ARM.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

clamage@Eng.Sun.COM (Steve Clamage) writes (in comp.lang.c++.moderated):

> 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.

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?

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
>clamage@Eng.Sun.COM (Steve Clamage) writes (in comp.lang.c++.moderated):
>
>> 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.
>
>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?

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.
---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

: clamage@Eng.Sun.COM (Steve Clamage) writes (in comp.lang.c++.moderated):

: > 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.

Normally, I think of "external linkage" as meaning that the identifier
gets an entry in the object file's linkage table(s).  (Of course,
that's implementation, not semantics.)  I presume declarations of
inline functions still include the function's body and must occur in
each translation that uses the function.  So, what kind of entry, if
any, should one now expect such declarations generate in the linkage
table(s)?  If none, then what does it mean to say that inline
functions have "external linkage"?  What's different now, except that
some program that used to be legal now violate the one-definition
rule?

Tom Payne


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]