Object lifetime

Object lifetime

• Temporary object lifetime
• Storage reuse
• Access outside of lifetime
  
  Every object has a lifetime, which is a runtime property: for any object, there is a moment during the execution of a program when its lifetime begins, and there is a moment when it ends.
  
  简单而言，对象生命周期的从初始化开始，到析构函数调用为止。
• For objects of class or aggregate types that are initialized by anything other than the trivial default constructor, lifetime begins when initialization ends.
• For objects of class types whose destructor is not trivial, lifetime ends when the execution of the destructor begins.
• For all other objects (class objects initialized by a trivial default constructor, non-class objects, array objects, etc.), lifetime begins when the properly-aligned storage for the object is allocated and ends when the storage is deallocated or reused by another object.

Lifetime of an object is equal to or is nested within the lifetime of its storage, see storage duration.

Lifetime of a reference is exactly its storage duration (which makes dangling references possible).

Lifetimes of member objects and base subobjects begin and end following class initialization order.

Temporary object lifetime

Temporary objects are created in various situations: binding a reference to a prvalue, returning a prvalue from a function, cast to a prvalue, throwing an exception, entering an exception handler, and in some initializations. In every case, all temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created.

If multiple temporary objects were created, they are destroyed in the order opposite to the order of creation. This is true even if that evaluation ends in throwing an exception.

There are two exceptions from that:

• The lifetime of a temporary object may be extended by binding to a const lvalue reference or to an rvalue reference (since C++11), see reference initialization for details.
• The lifetime of a temporary object created when evaluating the default arguments of a default constructor used to initialize an element of an array ends before the next element of the array begins initialization.(since C++11)

Storage reuse

###Access outside of lifetime
If an object was destroyed (e.g. by explicit destructor call), but the storage was not deallocated, the following uses of the glvalue expression that identifies that object are undefined:
1. Lvalue to rvalue conversion (e.g. function call to a function that takes a value).
2. Access to a non-static data member or a call to a non-static member function.
3. Binding to reference to a virtual base class subobject.
4. dynamic_cast or typeid expressions.

If an object is recreated at the same memory location (e.g. by placement new), the glvalue becomes valid once again, if all of the following is true:

1. The storage occupied by the new object exactly overlays the storage occupied by the old object.
2. The new object has the same type as the old object, ignoring top-level cv-qualifiers.
3. The original object's type was not const-qualified.
4. The original object was not a class with const or reference non-static data members.
5. Both the original and the new objects are the most-derived objects of their type.

The above rules apply to pointers as well (binding a reference to virtual base is replaced by implicit conversion to a pointer to virtual base), with two additional rules:

1. static_cast of a pointer to storage without an object is only allowed when casting to (possibly cv-qualified) void*.
2. Pointers to storage without an object that were cast to possibly cv-qualified void* can only be static_cast to pointers to possibly cv-qualified char or pointer to possibly cv-qualified unsigned char.

During construction and destruction, other restrictions apply, see virtual function calls during construction and destruction.

Virtual function call during construction and destruction

When a virtual function is called directly or indirectly from a constructor or from a destructor (including during the construction or destruction of the class’s non-static data members, e.g. in a member initializer list), and the object to which the call applies is the object under construction or destruction, the function called is the final overrider in the constructor’s or destructor’s class and not one overriding it in a more-derived class. In other words, during construction or destruction, the more-derived classes do not exist.

When constructing a complex class with multiple branches, within a constructor that belongs to one branch, polymorphism is restricted to that class and its bases: if it obtains a pointer or reference to a base subobject outside this subhierarchy, and attempts to invoke a virtual function call (e.g. using explicit member access), the behavior is undefined:

struct V {
    virtual void f();
    virtual void g();
};
struct A : virtual V {
    virtual void f(); // A::f is the final overrider of V::f in A
};
struct B : virtual V {
    virtual void g(); // B::g is the final overrider of V::g in B
    B(V*, A*);
};
struct D : A, B {
    virtual void f(); // D::f is the final overrider of V::f in D
    virtual void g(); // D::g is the final overrider of V::g in D
    // note: A is initialized before B
    D() : B((A*)this, this)
    {
    }
};
// the constructor of B, called from the constructor of D
B::B(V* v, A* a)
{
    f(); // virtual call to V::f (although D has the final overrider, D doesn't exist)
    g(); // virtual call to B::g, which is the final overrider in B 
    v->g(); // v's type V is base of B, virtual call calls B::g as before
    a->f(); // a’s type A is not a base of B. it belongs to a different branch of the
            // hierarchy. Attempting a virtual call through that branch causes
            // undefined behavior even though A was already fully constructed in this
            // case (it was constructed before B since it appears before B in the list
            // of the bases of D). In practice, the virtual call to A::f will be
            // attempted using B's virtual member function table, since that's what
            // is active during B's construction)
}