Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #531

Re: Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d)

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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