🚀 go-pugleaf

JdeBP@jba.co.uk wrote:
|> Further to the global initialisation/cleanup discussion, can anyone tell me
|> when `woggle::~woggle' is called in the following program ?  Is undefined
|> behaviour invoked ?

|> If you think that the program is non-conforming (aside from any
|> typographical mistakes that I make, which I'm sure that you'll overlook in
|> view of the latesness of the hour, and the fact that I'm typing this in by
|> hand) please explain where and why it is non-conforming.

Fergus Henderson has done this, but IMHO, he didn't address the real
problem I think you are trying to raise.

The problem is *not* unique to operator delete: in general, it can occur
in any function called from the destructor of a static object that
contains a static object.

In general, static objects will *not* work in functions called from the
destructors of other static objects *unless* the same function was
called during the constructor (or before).  I believe that this is
implicit in the standard, in section 3.6.3, which states that static
objects will be destructed in the reverse order of there construction.
For a given static object, x, any local static objects in functions
called by the destructor will have already been destructed unless the
function was called (and the local static object constructed) *before*
the construction of x.

There are at least two open points in my mind:

1. When should a local static object be destructed if the block
containing it is first executed in the destructor of a static object?  A
(too) literal interpretation of the current wording would suggest that
it must be destructed *before* destructing the object which triggered
its construction, since it was certainly constructed after that object.

2. When is construction considered to take place for the purpose of this
ordering.  In particular:

	class A { A() {} } ;
	class B { B() { static A a ; } } ;
    B                   b ;

Which should be destructed first, the local static in B::B(), or the
global?  (The constructor of the global encompasses that of the local.
Ordering by start of the constructor gives: b, a; by finish of the
constructor a, b.)

The easiest solution for the committee would be probably be to just
change the wording in 3.6.3 to say that all nonlocal statics are
destructed, in the reverse order of their construction, then all local
statics, in an undefined order.  (And perhaps add a mention that statics
that have not been constructed will *not* be destructed.  Although I
would consider this just common sense, we have to consider that the
standard may be read and interpreted by people without common sense.)
This is also a fairly simple rule to implement (I think: comments from
implementers...).  Can anyone think of any situations where it will
cause problems for the users?
-- 
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. ]