20.7.2.2/1 (N3376) 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.
813. "empty" undefined for shared_ptr
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813

20.7.2.2.1/9 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,
to cover nullptr_t case.
758. shared_ptr and nullptr
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758

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 definition.

This causes a contradiction:
20.7.2.2.1/10 sets a postcondition use_count() == 1 on
shared_ptr(nullptr, d). But 20.7.2.2.5/7 says the return value of
use_count() is "0 when *this is empty".


Proposed resolution:
Replace the last 2 words in 20.7.2.2/1
 ... empty if it does not own a pointer.
to
 ... empty if it does not own an object.


Besides that, I want to know if it is (or was) possible or not to define
shared_ptr(nullptr) (including some variants with deleter and allocator)
is empty. It seems to be less surprising. FYI, please see the following
question on stackoverflow.
http://stackoverflow.com/questions/11164354/does-the-standard-behavior-for-deleters-differ-between-shared-ptr-and-unique-ptr

--
k_satoda


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]