Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Daniel Krügler<daniel.kruegler@googlemail.com> |
|---|---|
| Newsgroups | comp.std.c++ |
| Subject | Re: Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d) |
| Date | 2012-06-24 00:03 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <js5elk$g0$1@dont-email.me> (permalink) |
| References | <4FE565B7.1070406@f2.dion.ne.jp> |
Am 23.06.2012 22:13, schrieb Kazutoshi Satoda:
> 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.
I agree with your analysis, this looks like a library defect to me.
> 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.
I assume you mean these constructors:
template<class D> shared_ptr(nullptr_t p, D d);
template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
should create empty shared_ptr objects, right?
Note that
constexpr shared_ptr(nullptr_t) : shared_ptr() { }
is already empty by definition.
> It seems to be less surprising.
I agree that the current state is confusing. But I'm not sure whether
your suggested fix would cause less confusion taking all other
constructors together. Personally I would have preferred that for
template<class Y> explicit shared_ptr(Y* p);
template<class Y, class D> shared_ptr(Y* p, D d);
template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
template<class Y> shared_ptr(auto_ptr<Y>&& r);
template<class Y, class D> shared_ptr(unique_ptr<Y, D>&&r);
constructed with null pointer values the state would be empty in all cases.
I suspect it is too late for this change, though.
HTH& Greetings from Bremen,
Daniel Krügler
--
[ 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 ]
Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar
Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d) Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> - 2012-06-23 13:13 -0700
Re: Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d) Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-06-24 00:03 -0700
Re: Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d) Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> - 2012-06-24 23:49 -0700
csiph-web