🚀 go-pugleaf

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 
]