🚀 go-pugleaf

>>>>> Kaelin Colclasure <kaelin@bridge.com> writes:

> What behavior does the draft standard condone for the following
> scenario:

> 1) In a header file, an inline function is defined to contain a local
> static, like so:

> 2) Two seperate modules include this header file, call them A and B.
> A "initializes" foo():

> 3) B calls foo(), dereferences the pointer returned and prints its
> value:

> Some data points:

> MSVC++:	*foo() = 1
> G++:	*foo() = 0
> Sun C++:*foo() = 0

> My intuition is that MSVC++ is doing the "right" thing (gasp), and what
> "should" be the standard thing.

G++ and Sun conform to the current working paper for this example.  If
foo had been explicitly declared 'extern inline', or if it were a member
function, MS would be correct.

Jason
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <u9g2g5xbre.fsf@yorick.cygnus.com> jason@cygnus.com (Jason Merrill) writes:

    >> What behavior does the draft standard condone for the following
    >> scenario:

    >> 1) In a header file, an inline function is defined to contain a
    >> local static, like so:

    >> 2) Two seperate modules include this header file, call them A
    >> and B.  A "initializes" foo():

    >> 3) B calls foo(), dereferences the pointer returned and prints
    >> its value:

    >> Some data points:

    >> MSVC++: *foo() = 1 G++: *foo() = 0 Sun C++:*foo() = 0

    >> My intuition is that MSVC++ is doing the "right" thing (gasp),
    >> and what "should" be the standard thing.

    Jason>    G++ and Sun conform to the current working paper for
    Jason> this example.  If foo had been explicitly declared 'extern
    Jason> inline', or if it were a member function, MS would be
    Jason> correct.

Thanks for the clarification!  I wonder, though, if this isn't
something of a gratuitious inconsistancy.  For all other function
definitions, extern is the default-- you have to use the static
keyword to restrict the definition to file scope.  Now the draft is
saying that inline functions get exactly the *opposite* semantics
(ie. static is assumed, extern must be declared explicitly).

The only reason I can fathom for this is for compatibility with
existing, pre-standard C++ code-- and I'd say that's a pretty weak
basis given my intuition that this usage in existing implementations
should be pretty rare.  Am I just missing something?
-- 
// Kaelin Colclasure -------------------------------------------------------
// EMail: kaelin@bridge.com           Mail: Bridge Information Systems, Inc.
// Voice: (314)567-8463                     717 Office Parkway
//   Fax: (314)432-5391                     St. Louis, MO 63141


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

kaelin@bridge.com (Kaelin Colclasure) writes:

>What behavior does the draft standard condone for the following
>scenario:
>
>1) In a header file, an inline function is defined to contain a local
>static, like so:
>
>	inline int *
>	foo()
>	{
>	    static int i;
>	    return &i;
>	}
>
>2) Two seperate modules include this header file, call them A and B.
>A "initializes" foo():
>
>	#include "foo.h"
>	...
>	*foo() = 1;
>	...
>
>3) B calls foo(), dereferences the pointer returned and prints its
>value:
>
>	#include <iostream.h>
>	#include "foo.h"
>	...
>	cerr << "*foo() = " << *foo() << endl;
>	...
>
>Some data points:
>
>MSVC++:	*foo() = 1
>G++:	*foo() = 0
>Sun C++:*foo() = 0
>CFront:	"sorry, not implemented"
>
>My intuition is that MSVC++ is doing the "right" thing (gasp), and what
>"should" be the standard thing-- but I realize that the behavior I
>want requires mangling a global variable name or the moral
>equivalent.  I want to know if the standard requires this or leaves
>the behavior implementation defined...

The standard mandates the behaviour of g++ and Sun C++.
The reason is that an inline function by default has static linkage,
and so each translation unit gets its own copy.
To get the behaviour exhibited by MSVC++ from a draft
standard-conforming compiler, you would have to explicitly declare foo() as
`extern'.  That is, you would have to change the definition of foo() from

	inline int * foo() { ... }

to 

	extern inline int * foo() { ... }

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>The reason is that an inline function by default has static linkage,
>and so each translation unit gets its own copy.

Is this the case for class function members
(which are automatically inlined)?

>To get the behaviour exhibited by MSVC++ from a draft
>standard-conforming compiler, you would have to explicitly declare foo() as
>`extern'.

If the answer to the previous question is "yes",
does this also work for class function members?

damian
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

damian@molly.cs.monash.edu.au (Damian Conway) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>The reason is that an inline function by default has static linkage,
>>and so each translation unit gets its own copy.
>
>Is this the case for class function members
>(which are automatically inlined)?

No.  Member functions of a class always have external linkage (unless
the class is a local class declared inside a function).
So there should always be only one occurrence of a static variable
declared inside a class member function.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]