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
]

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

>But the question concerned static objects in a module that was never
>referenced.  (What I'm thinking of here are objects whose constructor
>registers them with some sort of container, and that are only accessed
>via that container.  If they are constructed, they will be accessed.
>But is there any guarantee that they will eventually be constructed?)

I've been trying to use as many weasel-words as possible here, and so I
wish you wouldn't keep pointing out the holes I'm deliberately
leaving unplugged. :-)

If a non-local static object is defined in a module, but no reference
is made to anything in that module, I don't believe the static object
is guaranteed to be constructed. If any object or function in that
module is referenced from outside the module, I believe all non-local
static objects are supposed to be constructed.

The problem as I see it is the draft standard still makes some promises
which I don't believe are possible to keep in all cases (even
forgetting about dynamic libraries). I don't think we have the final
word on exactly what you can expect about order of initializtion
and destruction of non-local static objects in different modules. The
current situation is that you can't depend on the order of construction
or destruction.

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

In article 96Mar29114545@gabi.gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
>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.
>    [...]
>|> Only two features are missing, compared to non-local static objects:
>
>|> 1. If you never reference an object, it is never initialized.
>
>But is this guaranteed by the standard anyway?

Assuming a program terminates normally (returning from main or
calling exit), I believe that every non-local static object defined
in a module that is somehow referenced will eventually be intialized.


>|> 2. The order of destruction remains unspecified. If that is a problem,
>|> possibly the static objects could be of a type which has a do-nothing
>|> destructor and a "destroy" member function which could be called
>|> explicitly at the proper time.
>
>I thought that the order of destruction was the reverse of
>initialization.

I believe the current draft says that. Few current implementations
ensure that result, and whether that guarantee will remain in the standard
is under discussion.

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

In article <4jp7st$lbj@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

|> In article 96Mar29114545@gabi.gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
|> >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.
|> >    [...]
|> >|> Only two features are missing, compared to non-local static objects:
|> >
|> >|> 1. If you never reference an object, it is never initialized.
|> >
|> >But is this guaranteed by the standard anyway?

|> Assuming a program terminates normally (returning from main or
|> calling exit), I believe that every non-local static object defined
|> in a module that is somehow referenced will eventually be intialized.

But the question concerned static objects in a module that was never
referenced.  (What I'm thinking of here are objects whose constructor
registers them with some sort of container, and that are only accessed
via that container.  If they are constructed, they will be accessed.
But is there any guarantee that they will eventually be constructed?)

|> >|> 2. The order of destruction remains unspecified. If that is a problem,
|> >|> possibly the static objects could be of a type which has a do-nothing
|> >|> destructor and a "destroy" member function which could be called
|> >|> explicitly at the proper time.
|> >
|> >I thought that the order of destruction was the reverse of
|> >initialization.

|> I believe the current draft says that. Few current implementations
|> ensure that result, and whether that guarantee will remain in the standard
|> is under discussion.

Good point.  It's true that I've yet to find a compiler that was conform
with the draft on this point.  It would be a shame if the guarantee
disappeared from the standard, however (unless there was something else
equally good to replace it).
--
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
                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
]