220 15587 <0b903f58-04a0-4f96-a953-2709feb4dd92@isocpp.org> article Path: news.gmane.org!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: RFC: Adding Symmetry Between shared_ptr and weak_ptr Date: Sun, 11 Jan 2015 23:59:22 -0800 (PST) Lines: 151 Approved: news@gmane.org Message-ID: <0b903f58-04a0-4f96-a953-2709feb4dd92@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2866_1773251657.1421049562945" X-Trace: ger.gmane.org 1421049569 2720 80.91.229.3 (12 Jan 2015 07:59:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2015 07:59:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQINX7ONUUCRUBHHD224E@isocpp.org Mon Jan 12 08:59:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f197.google.com ([209.85.220.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YAZuH-0000eg-1i for gclcip-std-proposals@m.gmane.org; Mon, 12 Jan 2015 08:59:25 +0100 Original-Received: by mail-vc0-f197.google.com with SMTP id hy4sf58309727vcb.0 for ; Sun, 11 Jan 2015 23:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=tGpnouc1SZPbClfdIDfdhw1gy//Z5MtC0oTUty+hUos=; b=X4Ct+1SIhcm4VofxBoWvfhG2NS7qjpoOc6IoZv5GgF0HpAGL/+IgbyrXBXUCI4XAJp 1VQYH25L+qTqYJLQwFMp5DsB88HjLKob8GXuJay/6OvXR7F8ukhQIpg4077xf86KQscJ ZFsxcpkZ5qIDTaYcx3T4tce+Ov82VPpGlP0TlYhPDZvYQwm/dgHvbYyUezB+zFZaFF1p aiMOvUaDF7AdrA4IanTJ0oz9cy3q49K/8HERRppvROzDrMLe+K5w1XZlMCtUuzW0frNZ Gh5YnzXaI0jfLtcRjGqGmkA9sKkRSxNrtISb3kPb7yquYoFIQXvH0Y+A+o/reSIgX3t4 TBxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=tGpnouc1SZPbClfdIDfdhw1gy//Z5MtC0oTUty+hUos=; b=Hq8isUWPfuhvh6Zc3B1x7xvlyi/sQSYvyV1yW02q0n02bRmN0Exnv+TfMki7ZWc2e3 BKwPqp7RI5tvo6w40gUxZBFwAXhEllMBtrEaDX0fjRq0xMMXT7i89RUdGdWPplrlG/oN ZG6iaxb9buD8FZ+gq8Hdg/orXZjeBTC5WjTHk+Er2EZcCHKYWuNGU0oMHga7Jvda+d/p zpsn8BUfUqWwWV9wV7e3umk3bdwrFhofmmDpO7WlM6BiB85x3+eH+1kMz6bD3r1zTFtp bLjI7ZiHP/WLEE5/lNa5s/ZLnoY7BNO2i+08pdpbx1L67gjua8ADKZtATWen7mbzy5g0 TMqA== X-Gm-Message-State: ALoCoQkKm5esFuraXr4TNAe8yWPoQat9yJXlYHbjZvzmIqhgL7asGSCNnOBrUNjxC3KXK3qLH3Fx X-Received: by 10.224.136.66 with SMTP id q2mr21950922qat.5.1421049563995; Sun, 11 Jan 2015 23:59:23 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.89.231 with SMTP id v94ls2639625qgd.18.gmail; Sun, 11 Jan 2015 23:59:23 -0800 (PST) X-Received: by 10.140.21.146 with SMTP id 18mr1545qgl.28.1421049563419; Sun, 11 Jan 2015 23:59:23 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15587 Archived-At: ------=_Part_2866_1773251657.1421049562945 Content-Type: multipart/alternative; boundary="----=_Part_2867_262546133.1421049562945" ------=_Part_2867_262546133.1421049562945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, January 11, 2015 at 3:55:01 AM UTC-8, David Krauss wrote: > On 2015=E2=80=9301=E2=80=9311, at 3:01 AM, Arthur O'Dwyer > wrote: >> >> I've got a rough draft of a proposal for the next meeting in May, and=20 would like to hear anyone's feedback on the format and content before then. > > There could be an rvalue-qualified overload of unlock() which does the=20 reset automatically. > auto wptr =3D std::move( sptr ).unlock(); That's an interesting idea. I think it's not a good idea, though, because= =20 it seems to be implying a general rule that if you do an operation on a=20 "moved-from" shared_ptr, then you implicitly reset the shared_ptr =E2=80=94= and=20 that's not currently the general rule. It seems attractive, but look how=20 much we'd have to "fix" to make it actually true as a general rule: shared_ptr sptr2 =3D std::move(sptr); // does reset weak_ptr wptr2 =3D std::move(sptr); // doesn't reset; merely=20 dispatches to the constructor taking const shared_ptr& shared_ptr sptr2 =3D std::move(wptr).lock(); // doesn't reset wptr,= =20 under the current standard I guess the most fundamental argument against your idea is that it does=20 *more* than just add symmetry to the standard; for symmetry we'd have to=20 add new &&-ref-qualified overloads of both shared_ptr::unlock *and*=20 weak_ptr::lock. I'm considering how to address your idea in the paper (probably in section= =20 5c or in a new 5d), but I'm not sure how to introduce it in a way that=20 doesn't feel redundant after we've already dismissed the idea of "fixing" weak_ptr wptr2 =3D std::move(sptr); // doesn't reset .. Also, ref-qualified overloads are pretty arcane, IMHO. In Frankfurt in=20 2009, the Committee apparently rejected a proposal (N2819) to add the &=20 ref-qualifier to a whole bunch of assignment operators. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941 http://stackoverflow.com/questions/21052377/whats-a-use-case-for-overloadin= g-member-functions-on-reference-qualifiers Does anyone know offhand if there currently exist any ref-qualified member= =20 functions in the standard library? =E2=80=93Arthur --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_2867_262546133.1421049562945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday, January 11, 2015 at 3:55:01 AM UTC-8, David Kra= uss wrote:
> On 2015=E2=80=9301=E2=80=9311, at 3:01 AM, Arthur O'Dwy= er <arthur....@gmail.com> wr= ote:
>>
>> I've got a rough draft of a prop= osal for the next meeting in May, and would like to hear anyone's feedback = on the format and content before then.
>
> There = could be an rvalue-qualified overload of unlock() which does the reset automatically.
>     auto wptr =3D std::move( sptr ).unlock();

That's an interesting idea. I think= it's not a good idea, though, because it seems to be implying a general ru= le that if you do an operation on a "moved-from" shared_ptr, then= you implicitly reset the shar= ed_ptr =E2=80=94 and that's not cur= rently the general rule. It seems attractive, but look how much we'd have t= o "fix" to make it actually true as a general rule:

    shared_ptr<T> sptr2 =3D std::move(sptr); &n= bsp;// does reset
&n= bsp;   weak_ptr<T> wptr2 =3D std::move(sptr);  // doesn't r= eset; merely dispatches to the constructor taking const shared_ptr&
    shared_pt= r<T> sptr2 =3D std::move(wptr).lock();  // doesn't reset wptr, u= nder the current standard

I guess the most fundamental argument against your idea is that = it does *more* than just add symmetry to the standard; for symmetry we'd ha= ve to add new &&-ref-qualified overloads o= f both shared_ptr::unlock= and weak_ptr::lock.

I'm considering how to address your idea in the pap= er (probably in section 5c or in a new 5d), but I'm not sure how to introdu= ce it in a way that doesn't feel redundant after we've already dismissed th= e idea of "fixing"

 =   weak_ptr<T> wptr2 =3D std::move(sptr);  // doesn't reset=

. Also, ref-qualified overloa= ds are pretty arcane, IMHO. In Frankfurt in 2009, the Committee apparently = rejected a proposal (N2819) to add the & ref-qualifier to a w= hole bunch of assignment operators.
http://www.open-std.or= g/jtc1/sc22/wg21/docs/lwg-closed.html#941
http://stackoverflo= w.com/questions/21052377/whats-a-use-case-for-overloading-member-functions-= on-reference-qualifiers

Does anyone know offha= nd if there currently exist any ref-qualified member functions in the stand= ard library?

=E2= =80=93Arthur

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_2867_262546133.1421049562945-- ------=_Part_2866_1773251657.1421049562945-- .