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

>In article GyB@netcom.com, smeyers@netcom.com (Scott Meyers) writes:
>>Suppose an inline function contains a local static variable.  How many
>>copies of the static are in the program?
[...]
>There was considerable discussion of this point, but my reading of the
>Sept 1994 draft contradicts what Fergus says.

In what way?

>Let's consider the simplest case: a nonmember inline function which does
>not have an extern declaration anywhere. (Change any of this, and the
>discussion changes.)
>
>The function has internal linkage according to 7.1.1p4, meaning that it is
>not the same function as any function in any other translation unit.

Yes, agreed.

>A static variable declared in this function has local scope and no linkage,
>according to 3.3.1p1 and 3.4p6, unless I have missed something that
>would create an exception for this case.

Also agreed.

>Therefore, if you include the same definition for this function in two
>translation units, they are distinct functions, and the local static
>variables are distinct variables. (This is certainly the case for
>non-inline static functions.)

Right.

>I think the Committee intends for there to be one copy of the static
>variable in the translation unit,

Yes, that's the semantics I described in my original reply.

>but I cannot find any wording in the
>Sept draft to allow this interpretation.

I certainly can't find any wording which would *disallow* that interpretation,
or that would allow any different interpretation.  Can you?

The only part which I can see which could possibly be contentious is
the wording in 7.1.2 where it descripts the effects of "inline".
Basically it says three different things:

 (1) the inline specifier acts as a hint to the compiler, which
     may be ignored.  The hint is that "inline substitution of the
     function body is to be preferred to the usual function call
     implementation".

 (2) the inline specifier affects linkage (see 3.4 and 7.1.1)

 (3) there are a bunch of restrictions on the use of inline functions
     (e.g. "a call to an inline function may not precede its definition")

The only thing which could possibly justify any other interpretation
would be (1).  But currently the working paper contains a whole bunch
of things which are non-normative, and it's pretty clear to me that the
hint is one of these.  It is talking about how to *implement* the
semantics specified by the standard.  The hint doesn't change those
semantics.  (Of course the inline specifier itself can, since it affects
linkage.)

Once you accept that the hint doesn't have any semantic effect, it's
clear that the semantics of inline non-member functions are just the
same as those of static non-inline non-member functions, and hence that
static variables inside such functions refer to exactly one object per
translation unit.

Does anyone disagree with that interpretation?

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <3dcka9$k69@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM writes:
>In article GyB@netcom.com, smeyers@netcom.com (Scott Meyers) writes:
>>Suppose an inline function contains a local static variable.  How many
>>copies of the static are in the program?
>>
>>  You cannot in general control or predict how many copies of an inline
>>  function will occur in a program.  An inline function generally has the
>>  semantics of a static function.  Is there then one copy of the static
>>  variable per copy of the function?  The ARM does not say.
>>
>>Fergus Henderson, however, replied:
>>
>>  The semantics of the function must not change depending on whether the
>>  compiler actually inlines the code or not. This means that there must be
>>  at most one copy of the static variable per translation unit.  Also the
>>  ARM quite clearly states that inline non-member functions have internal
>>  linkage. Together these clearly imply that there must be one copy of the
>>  static variable per translation unit. As far as I can see, there is no
>>  semantic ambiguity involved.
>>
>>Does the current draft address this point?  What is the current
>>understanding on this matter?
>
>There was considerable discussion of this point, but my reading of the
>Sept 1994 draft contradicts what Fergus says.

 I'm surprised! I find you say the same thing Fergus says!

>Let's consider the simplest case: a nonmember inline function which does
>not have an extern declaration anywhere. (Change any of this, and the
>discussion changes.)
>
>The function has internal linkage according to 7.1.1p4, meaning that it is
>not the same function as any function in any other translation unit.

 Right.

>A static variable declared in this function has local scope and no linkage,
>according to 3.3.1p1 and 3.4p6, unless I have missed something that
>would create an exception for this case.

 I think that is incorrect. The correct rule is given in
my ODR paper: the local static inherits the linkage of its
containing function. If the function is extern, so too is the
local static, if the function is internal, so too is the variable.
In particular, this rule accounts for the fact
that if an extern inline function exists, there is only
one local static variable.

 In my opinion ONLY typedefs, namespace aliases,
and possibly enumerators, have "no linkage".
In both cases what they _refer_ to have linkage, however.
The reason they have "no linkage" is that they ALWAYS have
internal linkage :-) In particular, all types and all variables --
including automatic variables -- have linkage. However
automatic variables do not have programmer defined linkage.
The linkage is inherited.

 It turns out this interpretation is natural in the
context of the ODR. For example:

 inline extern void f() {
  struct X {} x;
  throw x;
 };

In two translation units, we had better know for sure that
"x" has the same type in both cases -- and any RTTI had
better yield the same type_info . Furthermore, typeid MUST
work in these cases because one might well throw the x object,
and then apply the typeid operator in a catch clause.
The result had better not depend on which translation unit
the x was thrown from.

What that means is that there is a strong dynamical requirement
that X and x are identical and really do have linkage.
In particular, delete the word "extern" above and the
type of the thrown object had better _differ_ depending on
which function threw it (each translation unit has a distinct
function f()).

>Therefore, if you include the same definition for this function in two
>translation units, they are distinct functions, and the local static
>variables are distinct variables. (This is certainly the case for
>non-inline static functions.)

 But that is what Fergus said.

>I think the Committee intends for there to be one copy of the static
>variable in the translation unit, but I cannot find any wording in the
>Sept draft to allow this interpretation. A later version of the draft
>may address this point directly.

 It may when the ODR is considered. It is clear, however,
that there should not be more than one copy of a local static per
translation unit. People have this weird notion that a
function definition is somehow a callable body of object code.
Thats wrong. A function definition is a sequence of tokens.
Whether or not there is one definition or many is irrelevant:
there is only one function per program of each function with
external linkage and one per translation unit for each distinct
function defined with the same name but internal linkage.

 This has nothing to do with inlining. An inline function
with external linkage is a single function and a local static variable
contained therein is a single variable -- and the same variable in
every translation unit.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article GyB@netcom.com, smeyers@netcom.com (Scott Meyers) writes:
>Suppose an inline function contains a local static variable.  How many
>copies of the static are in the program?  If it were an out-of-line
>function, we'd expect one.  For an inline function, do we get one or do
>we get one per translation unit?  In earlier discussion of this topic
>on c.l.c++, Steve Clamage wrote:
>
>  You cannot in general control or predict how many copies of an inline
>  function will occur in a program.  An inline function generally has the
>  semantics of a static function.  Is there then one copy of the static
>  variable per copy of the function?  The ARM does not say.
>
>Fergus Henderson, however, replied:
>
>  The semantics of the function must not change depending on whether the
>  compiler actually inlines the code or not. This means that there must be
>  at most one copy of the static variable per translation unit.  Also the
>  ARM quite clearly states that inline non-member functions have internal
>  linkage. Together these clearly imply that there must be one copy of the
>  static variable per translation unit. As far as I can see, there is no
>  semantic ambiguity involved.
>
>Does the current draft address this point?  What is the current
>understanding on this matter?

There was considerable discussion of this point, but my reading of the
Sept 1994 draft contradicts what Fergus says.

Let's consider the simplest case: a nonmember inline function which does
not have an extern declaration anywhere. (Change any of this, and the
discussion changes.)

The function has internal linkage according to 7.1.1p4, meaning that it is
not the same function as any function in any other translation unit.
A static variable declared in this function has local scope and no linkage,
according to 3.3.1p1 and 3.4p6, unless I have missed something that
would create an exception for this case.

Therefore, if you include the same definition for this function in two
translation units, they are distinct functions, and the local static
variables are distinct variables. (This is certainly the case for
non-inline static functions.)

I think the Committee intends for there to be one copy of the static
variable in the translation unit, but I cannot find any wording in the
Sept draft to allow this interpretation. A later version of the draft
may address this point directly.

---
Steve Clamage, stephen.clamage@eng.sun.com

Suppose an inline function contains a local static variable.  How many
copies of the static are in the program?  If it were an out-of-line
function, we'd expect one.  For an inline function, do we get one or do
we get one per translation unit?  In earlier discussion of this topic
on c.l.c++, Steve Clamage wrote:

  You cannot in general control or predict how many copies of an inline
  function will occur in a program.  An inline function generally has the
  semantics of a static function.  Is there then one copy of the static
  variable per copy of the function?  The ARM does not say.

Fergus Henderson, however, replied:

  The semantics of the function must not change depending on whether the
  compiler actually inlines the code or not. This means that there must be
  at most one copy of the static variable per translation unit.  Also the
  ARM quite clearly states that inline non-member functions have internal
  linkage. Together these clearly imply that there must be one copy of the
  static variable per translation unit. As far as I can see, there is no
  semantic ambiguity involved.

Does the current draft address this point?  What is the current
understanding on this matter?

Thanks,

Scott