🚀 go-pugleaf

kanze@gabi-soft.fr (J. Kanze) s'icrit :
> 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?  I know that I have a
> significant number of static objects which must be initialized before
> main (but in any order), but I have always believed that this works
> because of the way current compilers work, and not because of anything
> in the standard.
> 
> |> 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.  This is what it says in the January draft, at least.
> Has this been changed?

I think that the order of destruction of static objects is
unspecified, only because the order of construction is unspe-
cified.

Which ever order the compiler chooses, the order of destruction
of the same static objects MUST be the exact opposite of their
construction order ! This is compiler-dependent.

I suggest the standard allows for static class constructors to
remove this compiler dependence !
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]