This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

462. Destroying objects with static storage duration

Section: 6.9.3.4 [basic.start.term], 17.2.2 [cstdlib.syn] Status: NAD Submitter: Bill Plauger Opened: 2004-03-23 Last modified: 2023-02-07

Priority: Not Prioritized

View all issues with NAD status.

Discussion:

3.6.3 Termination spells out in detail the interleaving of static destructor calls and calls to functions registered with atexit. To match this behavior requires intimate cooperation between the code that calls destructors and the exit/atexit machinery. The former is tied tightly to the compiler; the latter is a primitive mechanism inherited from C that traditionally has nothing to do with static construction and destruction. The benefits of intermixing destructor calls with atexit handler calls is questionable at best, and very difficult to get right, particularly when mixing third-party C++ libraries with different third-party C++ compilers and C libraries supplied by still other parties.

I believe the right thing to do is defer all static destruction until after all atexit handlers are called. This is a change in behavior, but one that is likely visible only to perverse test suites. At the very least, we should permit deferred destruction even if we don't require it.

[If this is to be changed, it should probably be changed by CWG. At this point, however, the LWG is leaning toward NAD. Implementing what the standard says is hard work, but it's not impossible and most vendors went through that pain years ago. Changing this behavior would be a user-visible change, and would break at least one real application.]

[ Batavia: Send to core with our recommendation that we should permit deferred destruction but not require it. ]

[ Howard: The course of action recommended in Batavia would undo LWG issue 3⁽ⁱ⁾ and break current code implementing the "phoenix singleton". Search the net for "phoenix singleton atexit" to get a feel for the size of the adverse impact this change would have. Below is sample code which implements the phoenix singleton and would break if atexit is changed in this way: ]

#include <cstdlib>
#include <iostream>
#include <type_traits>
#include <new>

class A
{
    bool alive_;
    A(const A&);
    A& operator=(const A&);
public:
    A() : alive_(true) {std::cout << "A()\n";}
    ~A() {alive_ = false; std::cout << "~A()\n";}
    void use()
    {
        if (alive_)
            std::cout << "A is alive\n";
        else
            std::cout << "A is dead\n";
    }
};

void deallocate_resource();

// This is the phoenix singleton pattern
A& get_resource(bool create = true)
{
    static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf;
    static A* a;
    if (create)
    {
        if (a != (A*)&buf)
        {
            a = ::new (&buf) A;
            std::atexit(deallocate_resource);
        }
    }
    else
    {
        a->~A();
        a = (A*)&buf + 1;
    }
    return *a;
}

void deallocate_resource()
{
    get_resource(false);
}

void use_A(const char* message)
{
    A& a = get_resource();
    std::cout << "Using A " << message << "\n";
    a.use();
}

struct B
{
    ~B() {use_A("from ~B()");}
};

B b;

int main()
{
    use_A("from main()");
}

The correct output is:

A()
Using A from main()
A is alive
~A()
A()
Using A from ~B()
A is alive
~A()

[ Bellevue: Confirmed no interaction with quick_exit. Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change, as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard. Bill agrees issue is no longer serious, and accepts NAD. ]

Proposed resolution: