Page History

The creation of dynamically allocated objects in C++ happens in two stages. The first stage is responsible for allocating sufficient memory to store the object, and the second stage is responsible for initializing the newly allocated chunk of memory, depending on the type of the object being created.

Similarly, the destruction of dynamically allocated objects in C++ happens in two stages. The first stage is responsible for finalizing the object, depending on the type, and the second stage is responsible for deallocating the memory used by the object. The C++ Standard, [basic.life], paragraph 1 , states [ISO/IEC 14882-2014], states the following:

The lifetime of an object is a runtime property of the object. An object is said to have non-trivial initialization if it is of a class or aggregate type and it or one of its members is initialized by a constructor other than a trivial default constructor. [Note: initialization by a trivial copy/move constructor is non-trivial initialization. — end note] The lifetime of an object of type T begins when:
— storage with the proper alignment and size for type T is obtained, and
— if the object has non-trivial initialization, its initialization is complete.
The lifetime of an object of type T ends when:
— if T is a class type with a non-trivial destructor, the destructor call starts, or
— the storage which the object occupies is reused or released.

For a dynamically allocated object, these two stages are typically handled automatically handled by using the new and delete operators. The expression new T for a type T results in a call to operator new() to allocate sufficient memory for T. If memory is successfully allocated, the default constructor for T is called. The result of the expression is a pointer P to the object of type T. When that pointer is passed in the expression delete P, it results in a call to the destructor for T. After the destructor completes, a call is made to operator delete() to deallocate the memory.

When a program creates a dynamically allocated object is created by means other than a call to the new operator, it is said to be manually managing the lifetime of that object. This situation arises when using other allocation schemes to obtain storage for the dynamically allocated object, such as using an allocator object or malloc(). For instanceexample, a custom container class may allocate a slab of memory in a reserve() function in which subsequent objects will be stored. See MEM51-CPP. Properly deallocate dynamically allocated resources for further information on dynamic memory management and MEM08-CPP. Use new and delete rather than raw memory allocation and deallocation for the recommendation to use new and delete whenever possible.

When manually managing the lifetime of an object, the constructor must be called to initiate the lifetime of the object. Similarly, the destructor must be called to terminate the lifetime of the object. Use of an object outside of its lifetime may result in is undefined behavior. The constructor for an object may be called explicitly by An object can be constructed either by calling the constructor explicitly using the placement new operator operator or by calling the construct() function of an allocator object. The destructor for an object may be called An object can be destroyed either by calling the destructor explicitly or by calling the the destroy() function of an allocator object.

Noncompliant Code Example

In this noncompliant code example, a class with nontrivial initialization (due to the presence of a user-provided constructor) is created with a call to std::malloc(). However, the constructor for the object is never called, resulting in undefined behavior when the class is later accessed by calling s->f().

Code Block

bgColor	#FFcccc
lang	cpp

#include <cstdlib>

struct S {
  S();
  
  void f();
};

void fg() {
  S *s = static_cast<S *>(std::malloc(sizeof(S)));
 
  s->f();
 
  std::free(s);
}

Compliant Solution

In this compliant solution, the constructor and destructor are both explicitly called. Further, to reduce the possibility of the object being used outside of its lifetime, the underlying storage is a separate variable from the live object.

Code Block

bgColor	#ccccff
lang	cpp

#include <cstdlib>
#include <new>

struct S {
  S();
  
  void f();
};

void fg() {
  void *ptr = std::malloc(sizeof(S));
  S *s = new (ptr) S;

  s->f();
 
  s->~S();
  std::free(sptr);
}

Noncompliant Code Example

In this noncompliant code example, a custom container class uses an allocator object to obtain storage for arbitrary element types, but it . While the copy_elements() function is presumed to call copy constructors for elements being moved into the newly allocated storage, this example fails to explicitly call object constructorsthe default constructor for any additional elements being reserved. If such an element that has been reserved is accessed through the operator[]() function, it results in undefined behavior, depending on the type T.

Code Block

bgColor	#FFcccc
lang	cpp

#include <memory>

template <typename T, typename Alloc = std::allocator<T>>
class Container {
  T *UnderlyingStorageunderlyingStorage;
  size_t NumElementsnumElements;
  
  void CopyElementscopy_elements(T *Fromfrom, T *Toto, size_t Countcount);
  
public:
  void reserve(size_t Countcount) {
    if (Countcount > NumElementsnumElements) {
      Alloc Aalloc;
      T *Pp = Aalloc.allocate(Countcount); // Throws on failure
      try {
        CopyElementscopy_elements(UnderlyingStorageunderlyingStorage, Pp, NumElementsnumElements);
      } catch (...) {
        Aalloc.deallocate(Pp, Countcount);
        throw;
      }
      UnderlyingStorageunderlyingStorage = Pp;
    }
    NumElementsnumElements = Countcount;
  }
  
  T &operator[](size_t Idxidx) { return UnderlyingStorageunderlyingStorage[Idxidx]; }
  const T &operator[](size_t Idxidx) const { return UnderlyingStorageunderlyingStorage[Idxidx]; }
};

Compliant Solution

In this compliant solution, the newly allocated memory is all elements are properly initialized by explicitly calling object copy or default constructors for T:.

Code Block

bgColor	#ccccff
lang	cpp

#include <memory>

template <typename T, typename Alloc = std::allocator<T>>
class Container {
  T *UnderlyingStorageunderlyingStorage;
  size_t NumElementsnumElements;
  
  void CopyElementscopy_elements(T *Fromfrom, T *Toto, size_t Countcount);
  
public:
  void reserve(size_t Countcount) {
    if (Countcount > NumElementsnumElements) {
      Alloc Aalloc;
      T *Pp = Aalloc.allocate(Countcount); // Throws on failure
      try {
        CopyElementscopy_elements(UnderlyingStorageunderlyingStorage, Pp, NumElementsnumElements);
        for (size_t i = NumElementsnumElements; i < Countcount; ++i) {
          Aalloc.construct(&Pp[i]);
        }
      } catch (...) {
        Aalloc.deallocate(Pp, Countcount);
        throw;
      }
      UnderlyingStorageunderlyingStorage = Pp;
    }
    NumElementsnumElements = Countcount;
  }
  
  T &operator[](size_t Idxidx) { return UnderlyingStorageunderlyingStorage[Idxidx]; }
  const T &operator[](size_t Idxidx) const { return UnderlyingStorageunderlyingStorage[Idxidx]; }
};

Exceptions

MEM33MEM53-CPP-EX1: If the object is trivially constructable, it need not have its constructor explicitly called to initiate the object's lifetime. If the object is trivially destructible, it need not have its destructor explicitly called to terminate the object's lifetime. These properties can be tested by calling calling std::is_trivially_constructible() and std::is_trivially_destructible() from <type_traits>. For instance, integral types such as int and long long do not require an explicit constructor or destructor call.

Risk Assessment

Failing to properly construct or destroy an object leaves its internal state inconsistent, which can result in undefined behavior and accidental information exposure.