3008. make_shared (sub)object destruction semantics are not specified

Section: 23.11.3.6 [util.smartptr.shared.create] Status: New Submitter: Glen Joseph Fernandes Opened: 2017-08-06 Last modified: 2017-11-09

Priority: 2

View other active issues in [util.smartptr.shared.create].

View all other issues in [util.smartptr.shared.create].

View all issues with New status.

Discussion:

The remarks for the make_shared and allocate_shared functions do not specify how the objects managed by the returned shared_ptr are destroyed. It is implied that when objects are constructed via a placement new expression, they are destroyed by calling the destructor, and that when objects are constructed via an allocator, they are destroyed using that allocator. This should be explicitly specified.

[2017-11 Albuquerque Wednesday night issues processing]

Priority set to 2

Proposed resolution:

This resolution is relative to N4687.

  1. Edit 23.11.3.6 [util.smartptr.shared.create] as indicated:

    template<class T, ...>
    shared_ptr<T> make_shared(args);
    template<class T, class A, ...>
    shared_ptr<T> allocate_shared(const A& a, args);
    

    […]

    -7- Remarks:

    1. […]

    2. (7.9) — When the lifetime of the object managed by the return value ends, or when the initialization of an array element throws an exception, the initialized elements should be destroyed in the reverse order of their construction.

    3. (7.?) — When a (sub)object of a non-array type U that was initialized by make_shared is to be destroyed, it shall be destroyed via the expression pv->~U() where pv points to that object of type U.

    4. (7.?) — When a (sub)object of a non-array type U that was initialized by allocate_shared is to be destroyed, it shall be destroyed via the expression allocator_traits<A2>::destroy(a2, pv) where pv points to that object of type cv-unqualified U and a2 of type A2 is a rebound copy of the allocator a passed to allocate_shared such that its value_type is remove_cv_t<U>.