Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Kazutoshi Satoda Newsgroups: comp.std.c++ Subject: Re: Contradicting definition of empty shared_ptr on shared_ptr(nullptr, d) Date: Sun, 24 Jun 2012 23:49:13 -0700 (PDT) Organization: unknown Lines: 87 Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: <4FE6E358.1020506@f2.dion.ne.jp> References: <4FE565B7.1070406@f2.dion.ne.jp> NNTP-Posting-Host: SlCBScSdZmHl8UXg44jn8bx0RuDqexqG6gsiIgY6pyk= Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: news.albasani.net fvyY4EYnLlTfQVKGkGkLaPfhHAc5tSgk2Rcx4iie3217PEruWRfdSnWgXafN6LzDR4n1KRezODIgns47fVvrXQ== X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Mon, 25 Jun 2012 06:58:33 +0000 (UTC) X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:S0YapFC34yxRSPy/HZd0whMEKO0= X-Original-Date: Sun, 24 Jun 2012 18:52:24 +0900 Xref: csiph.com comp.std.c++:534 Daniel Krügler wrote: > > Am 23.06.2012 22:13, schrieb Kazutoshi Satoda: (snip) >> >> 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. Yes. I forgot to put "Defect report:" on the subject. Sorry about that. >> 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 shared_ptr(nullptr_t p, D d); > template shared_ptr(nullptr_t p, D d, A a); > > should create empty shared_ptr objects, right? That's right. > Note that > > constexpr shared_ptr(nullptr_t) : shared_ptr() { } > > is already empty by definition. I wasn't aware of the delegating constructor at the first post. Thanks. ... it seems also lack noexcept though. unique_ptr(nullptr_t) has noexcept. Another defect or editorial thing? > 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 explicit shared_ptr(Y* p); > template shared_ptr(Y* p, D d); > template shared_ptr(Y* p, D d, A a); > template shared_ptr(auto_ptr&& r); > template shared_ptr(unique_ptr&&r); > > constructed with null pointer values the state would be empty in all cases. It would require a runtime check for null pointer for each and probably more. The design choice seems have been made on Boost design period not to have such checks. http://www.boost.org/doc/libs/1_31_0/libs/smart_ptr/shared_ptr.htm#constructors > > The postcondition that use count is 1 holds even if p is 0; invoking > delete on a pointer that has a value of 0 is harmless. (I can see this note at least through 1.31 to 1.49 (latest). I'm not sure the design rationale was really avoiding the runtime checks.) So I think this confusion is not really a new thing and somewhat acceptable, but was probably avoidable for really new nullptr_t case. > I suspect it is too late for this change, though. I also suspect that. Then I propose to fix just the apparent contradiction. -- 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 ]