I just read
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#3, which is
particularly interesting, as this is a problem I had to write a patch to
the MSVC runtime library for some time back.  While I totally agree with
the description of the problem, I certainly don't like the proposed
resolution.  If this resolution is adopted it will be extremely
difficult to prove that any program which uses local scope static
variables does not exhibit undefined behavior during termination via
exceptional code paths.

I think a much better resolution is to define the semantics of atexit
and static destructors in a stack-like fashion.  This has the added
advantage of being very easy to implement, patching the MSVC runtime
library to work in this fashion resulted in much more straightforward
code than the original broken implementation.

Under this resolution with the example given:

void F() { static T t; } // type T has a destructor

    int main()
    {
        atexit(F); // the only use of F
    }

The destructor for t would be pushed onto the top of the atexit stack,
and would execute as soon as function F completed.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In general I like this idea but I have a cuation: it is possible to
create a situation where the _atexit stack_ has a length which
oscillates between two limits (in particular N and N+1) forever. This
pre-suppsoses an interaction with the destruction of the static
instances. If we wrote:

 T::~T() { atexit( F ); }

what would the result be? After F::t is destroyed will a call of F()
re-create it?

Cheers, John.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan H Lundquist <jhl@sssonline.com> writes:

>I think a much better resolution is to define the semantics of atexit
>and static destructors in a stack-like fashion.

The description of exit processing in the C++ standard is
incoherent and self-contradictory, and is the subject of a
defect report.

THe C89 standard does not define what happens if a function
called during exit processing registers another function
with atexit.

C9X has fixed that omission by requiring stack-like behavior.
The recommended handling of the C++ defect report is also to
require stack-like behavior, and that will probably be the
resolution.

--
Steve Clamage, stephen.clamage@sun.com


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]