Destruction order of statically initialized, non-literal objects

Question

A recent question drew my attention to the way that constexpr has changed in C++14. The new feature is that a non-local variable with static storage duration may be initialized in the static initialization phase if its initializer consists of a constexpr constructor, even if the type of the variable isn't a literal type. More precisely, the new wording in [basic.start.init] is:

A constant initializer for an object o is an expression that is a constant expression, except that it may also invoke constexpr constructors for o and its subobjects even if those objects are of non-literal class types [Note: such a class may have a non-trivial destructor — end note]. Constant initialization is performed [...] if an object with static or thread storage duration is initialized by a constructor call, and if the initialization full-expression is a constant initializer for the object [...]

The typical example is std::unique_ptr, which "should never be worse that hand-written":

std::unique_ptr<int> p;   // statically initialized by [unique.ptr.single.ctor],
                          // requires no code excution
int main()
{
    p = std::make_unique<int>(100);
}

// p is destroyed eventually

Prior to this addition, statically initialized variables were either of reference type or of literal object type, and therefore had trivial destructors. But now a statically initialized global variable can have a non-trivial destructor.

How is such a destructor call ordered with respect to the destructors of dynamically initialized global objects, with respect to other statically initialized ones, and how are the destructor calls sequenced?

Answer 1

[basic.start.term]/1 (N4140) says:

If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized.

As I understand, this means that for the purpose of determinig the order of destruction, all static initialization is treated as dynamic (ordered or unordered) and the destructors are called in reverse order of this initialization.

Answer 2

Consider

If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized.

and

If the completion of the constructor or dynamic initialization of an object with static storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first.

Now,

Static initialization shall be performed before any dynamic initialization takes place.

Clearly this answers the first question: Since p is guaranteed to be initialized before any dynamic initialization is performed, the destructor is called after any dynamically initialized object is destroyed.

Essentially the second question, i.e. what order the destructions of several statically initialized variables have, is reduced to the ordering of the initialization of these:

Dynamic initialization of a non-local variable with static storage duration is either ordered or unordered. Definitions of explicitly specialized class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) have unordered initialization. Other non-local variables with static storage duration have ordered initialization.

The bold sentence includes all statically initialized objects that are not static data members of instantiated classes. They are ordered within one translation unit:

Variables with ordered initialization defined within a single translation unit shall be initialized in the order of their definitions in the translation unit.

So, to summarize:

• Variables which are subject of static initialization and are not static data members of an instantiated class are destroyed in the reverse order of definition in a translation file.

• ... those variables are always destroyed after any dynamically initialized object is destroyed.

However, despite possible argumentative mistakes, neither Clang nor GCC seem to implement it this way at the moment: Demo.