🚀 go-pugleaf

JdeBP@jba.co.uk wrote:

|> : Also, I think that the lifetime of the local static objects and global
|> : translation units (i.e. sets of global objects defined in them) should
|> : conform to the single stack-like semantics (actual implementation data
|> : structure may vary). In other words, the object/unit is 'pushed' when its
|> : construction starts (or ends). At the implementation-dependent moment
|> : after main() returns, the implementation shutdown code starts 'popping'
|> : objects/units from the stack and calling the appropriate destructors.

|> Although not implemented as a stack, you will find that many
|> implementations already do this, because one favourite means of
|> implementing global initialisation is to construct at link time a list of
|> all static duration objectsi from all translation units and bind them into
|> the program.  At runtime this list is traversed from one end to the other
|> to perform dynamic initialisation, and in the reverse direction to perform
|> destruction.

This is, in effect, what most implementations do.  By my reading of the
standard, however, it is *not* legal.  Given the following program (in
which all types with capital letters are classes with constructors and
destructors):

    extern int          f() ;
    A                   a1 ;
    int                 a2 = f() ;
    A                   a3 ;

    int
    f()
    {
        static A            a2a ;
        return 0 ;
    }

    int
    main()
    {
        return 0 ;
    }

According to 3.6.2, the static objects will be initialized in the order
a1, a2/a2a, a3.  (The initialization of a2 encompasses the
initialization of a2a.)  Thus, applying the rule from 3.6.3:
``Destruction [of static objects] is done in reverse order of
initialization'', the destructors must be called in the reverse order:
a3, a2a, a1.  In practice, this requires some sort of stack-like list,
since most compilers will not do enough flow analysis to determine the
exact order.  (In fact, I do not believe they can.  The static variable
in f() could be in a block goverened by an if whose condition depended
on the result of a call to getenv, for example.)

Note that in 3.6.3, the rule very definitly applies to ``static
objects''.  Given that in the preceding section (3.6.2), the notation of
``nonlocal static objects'' occurs consistently when local static
objects are not considered, I do not think one can attribute this to
carelessness on the part of the committee; IMHO, the intent is clear.

Another interesting case:

    A                   a1 ;
    A                   a2 ;
    A                   a3 ;
    //  ...

The constructor of a2 throws an exception (not caught, of course).  In
no case can the compiler be allowed to call the destructor to a3.  All
of the compilers I've tested do.  Which in practice means that you
cannot safely let an exception escape from a constructor unless you can
guarantee that the type can never be used as a static variable with file
scope.  (Gee, and I always thought that one of the main reasons for
using exceptions was error reporting from constructors.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]