🚀 go-pugleaf

In article 1B39@trcinc.com, Rich Paul <rpaul@trcinc.com> writes:
>Jeffrey C. Gealow wrote:
>> 
>> In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
>> (Steve Clamage) writes:
>> 
>>    I believe a reasonable solution to the problem of initialization of
>>    non-local static data is not to use non-local static data!
>> 
>>    Instead of a static data object or static class data member, use a
>>    function with a local static object.
>> 
>> But this adds the overhead of the function call mechanism to every use
>> of the object.
>> 
>
>If you inline the function, are you guarenteed a 
>single instance, or might there be one in each 
>compilation unit, or in each invocation of the 
>function?

The ARM was vague on that point, and compilers have differed in their
behavior. On the one hand, inline functions are supposed to have the
semantics of static functions, meaning a separate copy of the function
(and of its static variables) in each translation unit where it is used.
On the other hand, it cannot be the case that a class member function
exists in several copies; that would violate the One-Definition Rule.

The latest draft standard allows for both internal and external linkage of
inline functions.

All class member functions have external linkage, meaning the program
behaves as if only one copy of the function exists in the program.

A non-member function may be declared "extern inline":
	extern inline T& Tobject() { static T t; return t; }
This example means the program behaves as if only one copy of the function
exists, including any local static data. It is up to the compiler to
figure out how to arrange for that to happen.

A non-member inline function has internal linkage (behaves like an ordinary
static function) if it is not declared "extern".

I don't think any compilers support this new set of rules yet, but eventually
all compilers will.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]