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

2594. Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d)

Section: 20.3.2.2 [util.smartptr.shared] Status: New Submitter: Kazutoshi Satoda Opened: 2016-02-20 Last modified: 2016-06-20

Priority: 3

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

View all issues with New status.

Discussion:

Latest draft (N4567) 20.3.2.2 [util.smartptr.shared] p1 says:

A shared_ptr object is empty if it does not own a pointer.

Please note that it says "own a pointer". This definition was added as the resolution for LWG defect 813(i).

20.3.2.2.2 [util.smartptr.shared.const] p8 says about the effect of shared_ptr(nullptr_t p, D d):

Effects: Constructs a shared_ptr object that owns the object p and the deleter d.

Please note that it says "owns the object". This was intentionally changed from "the pointer" as a part of resolution for LWG defect 758(i), to cover nullptr_t case.

Since shared_ptr(nullptr, d) owns an object of type nullptr_t, but does not own a pointer, it is said as "empty" by a strict reading of the above mentioned definition in 20.3.2.2 [util.smartptr.shared] p1.

These cause a contradiction:

20.3.2.2.2 [util.smartptr.shared.const] p9 sets a postcondition use_count() == 1 on shared_ptr(nullptr, d). But 20.3.2.2.6 [util.smartptr.shared.obs] p7 says that the return value of use_count() is "0 when *this is empty".

Proposed wording changes:

Replace the last 2 words in 20.3.2.2 [util.smartptr.shared] p1 from

[…] empty if it does not own a pointer.

to

[…] empty if it does not own an object.

Note that shared_ptr(nullptr_t) is defined to be empty in synopsis in 20.3.2.2 [util.smartptr.shared].

constexpr shared_ptr(nullptr_t) noexcept : shared_ptr() { }

It could be less confusing if shared_ptr(nullptr, d) could be defined to be empty. But it seems too late to change that (which means changing whether the deleter is called or not, see this Stackoverflow article). Then I'm proposing just fix the contradiction.

Proposed resolution:

This wording is relative to N4594.

  1. Change 20.3.2.2 [util.smartptr.shared] p1 as indicated:

    -1- The shared_ptr class template stores a pointer, usually obtained via new. shared_ptr implements semantics of shared ownership; the last remaining owner of the pointer is responsible for destroying the object, or otherwise releasing the resources associated with the stored pointer. A shared_ptr object is empty if it does not own an objecta pointer.