220 28960 article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Is World's Dumbest Pointer still on the table?!? Date: Wed, 19 Oct 2016 02:38:30 -0700 (PDT) Lines: 202 Approved: news@gmane.org Message-ID: References: <8a6731f7-1c9b-482d-817e-c2374fc9ae1b@isocpp.org> <7d817482-e7c3-4724-9501-738d4c9083d7@isocpp.org> <986ffd0c-7466-476a-96af-525aaf8b24ea@isocpp.org> <5adf05e5-edb4-4706-816b-59b71d5c1a6f@isocpp.org> <3241f484-0d5a-4363-8ddd-d3813a54fcb1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_22_1099345371.1476869910284" X-Trace: blaine.gmane.org 1476869947 15040 195.159.176.226 (19 Oct 2016 09:39:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 09:39:07 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBF76TTAAKGQESFSYZCQ@isocpp.org Wed Oct 19 11:38:59 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f197.google.com ([209.85.216.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwnKR-000874-EE for gclcip-std-proposals@m.gmane.org; Wed, 19 Oct 2016 11:38:31 +0200 Original-Received: by mail-qt0-f197.google.com with SMTP id g49sf16355694qtc.7 for ; Wed, 19 Oct 2016 02:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+skslWMhhCMYrf6skaxfGoaiVRSzUbPnKz+3mr62qbU=; b=o3Sq+HH3YIUhMaycEMiI+TJstZmpTMmXebcJ4zEQ02OndsPERbfvmKMYzv3LCgRZOb hKUVrCI7oYqS6gAlQQNmDVYkw8l6P82jWac47cklgeksEUD+ar+AyZJ9KqFCVa20VaWK Szgy2EvGyRAZQ/RKMnq+fmMsUPgm9/NDTdb1i0uwWGyjq1WfQNA1RkifTJUiZYj15mHY akbaPVVPFI8TSjHK3/AYrWmMKOoaLiMuPk8VVBB31SuL8Pl2tG63ZSKiN3SFpk5UUnZa Mn+WOClutqkASS1hYq1EL12Esf98Cu5Aa5iQaX35qg2D7LRSN4JEAfPi229MkJdZJAvz uZZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+skslWMhhCMYrf6skaxfGoaiVRSzUbPnKz+3mr62qbU=; b=x8+y+BK0pOr1uuaqlnMf0yePYIhAY4F4aP9Xdm6kqMxq5abVGC9igsQa99VjDI40qE K97VMX9luX8N3XyeeO/42Q/tq28NQT+qdjjTm5uRMyLhyP1+LiHCpSFB/ejtm75boD6Z o0mRtD/HzSheloVDoCu/L2lKONhDTgl/Dl4MeYMoEV2EoH6n/paB9XDi8t9y1bfLVTjv q6Pzv0H9y3A79Sy7WE8uTqfzpYPZNwl4nQOC1nRM/faHGiWE+fs2knJCUsDsuS32G/Gy 0Sj70xw5dsjM9EDuaIHqCtt7WMFd5WjVldOQda/BjC1ZqfiA8tCONRBVMJxn+NkmSG5C ezdw== 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:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=+skslWMhhCMYrf6skaxfGoaiVRSzUbPnKz+3mr62qbU=; b=f0OL/qXT8LU0MYzyUvQwPBmigdHs1vADZle2J0Kf0t7teySi6ZEByG4RhYRPA3j2gB OsKOoFMiBuJrUEPjUHJMfyrmu9Q5tmowAwvOj0e61lJ4fbYSPrY2RXzfOdkbN80eNuPT D+oxEk4q6nsXvKWY3CFJQVcfppPSbC4CdZs+nN/UFSnpbjUq7MnqPltU3H5SIsrQrxbp Bq+1iljI0HErJLg1IGJKlQ8U3ehzHQtl+QF0nJ6RbUiH0r5R1eG5xk40C6bmO1HACABt eNPsISGnDhKbhHxtF9f1tqmQrEmw2DW1uOuyrEsWweUUgtOMFjTm5c0QdMlx/1lpGIs1 J0RQ== X-Gm-Message-State: AA6/9RkBwWGez0iEuqdr9/XKQCtgyFY0o7XbMRIxR7MsqKJlTNp3iabTbTs/V3ACN1AaPQ== X-Received: by 10.200.53.101 with SMTP id z34mr1540185qtb.72.1476869913601; Wed, 19 Oct 2016 02:38:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.141.15 with SMTP id p15ls635987iod.36.gmail; Wed, 19 Oct 2016 02:38:31 -0700 (PDT) X-Received: by 10.36.77.75 with SMTP id l72mr451856itb.1.1476869911836; Wed, 19 Oct 2016 02:38:31 -0700 (PDT) In-Reply-To: <3241f484-0d5a-4363-8ddd-d3813a54fcb1@isocpp.org> X-Original-Sender: frankhb1989@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:28960 Archived-At: ------=_Part_22_1099345371.1476869910284 Content-Type: multipart/alternative; boundary="----=_Part_23_1012790129.1476869910284" ------=_Part_23_1012790129.1476869910284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UT= C+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=93= =EF=BC=9A > > Ok,=20 > I hope we all agree reset(T*) and release() have new meaning in the=20 > context of a observer_ptr. Ok? > > For you, it is not a problem - the class is free to add whatever meaning= =20 > it wants to. > > I simply argue, it can well be a problem and potentially adding a=20 > confusion. > > auto p =3D foo(); > > if(cond(p)) > p.reset(hello.getBar()); > > > > All I am saying, this code above, for current smart pointers, meant - p= =20 > now *has* the bar object. > > With observer_ptr into the picture, it might also mean - p now *points to= *=20 > a bar. > > For current smart pointers in the standard, it is also true. The=20 assumption is just further weaken (correctly). =20 > There is some overloading, which I personally find unfortunate and not=20 > well justified.=20 > > If you do need the meaning you want, you can introduce a non-member=20 function template only for smart pointers having such property, with a=20 clearer, unambiguous name, e.g. `change_owning`, rather than `reset`. =20 > That's all. > > - > > Now lets look at release, which has also a different problem. > > std::unique_ptr::release > std::shared_lock::release > std::unique_lock::release > std::pmr::monotonic_buffer_resource::release > std::pmr::unsynchronized_pool_resource::release > > > What is common b/w these all?=20 > > They all give up a resource, which affects other objects in the system. > > In general, right now, when you see release() in code, something quite=20 > important, worth noting is happening.=20 > Something possibly requiring some other actions to take care of. > > None of these are trivial operation.=20 > > observer_ptr makes it trivial.=20 > It makes it only about *itself*, it does not affect other objects and=20 > state. > > Ok, for you it might not be a problem. > > I only argue, it might well be - release() statement in code loses from= =20 > its importance. > > *The important uses of release() will be accompanied of trivial uses of= =20 > it.* > Not a good thing. > > The problem here is the name clashes within different use cases, whether= =20 taking observer_ptr into account or not. You have to do further (on the=20 returned value from the smart pointers' `release()`) to make them similar,= =20 that's already somewhat awful (error-prone) if both styles are used in the= =20 same codebase. I do want to "detach" smart pointers or locks. But for backward=20 compatibility, perhaps it is easier to rename the latter ones. =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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/a17356b2-2545-444a-9db5-98c36d90c6f4%40isocpp.or= g. ------=_Part_23_1012790129.1476869910284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2016=E5=B9=B410=E6=9C=8819=E6=97=A5=E6= =98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=884:30:37=EF=BC=8Cmihailn...@= gmail.com=E5=86=99=E9=81=93=EF=BC=9A
Ok,
I hope we all agree reset(T*) an= d release() have new meaning in the context of a observer_ptr. Ok?

For you, it is not a problem - the class is free to add wh= atever meaning it wants to.

I simply argue, it can= well be a problem and potentially adding a confusion.

=
auto p =3D foo();

if(cond(p))
=C2=A0p.reset(hello.getBar());

=


All I am sayin= g, this code above, for current smart pointers, meant - p now has th= e bar object.

With observer_ptr into the picture, = it might also mean - p now points to a bar.

For current smart pointers in the standard, it is also = true. The assumption is just further weaken (correctly).
=C2=A0
<= div>There is some=C2=A0overloading, which I personally find unfortunate and= not well justified.

If you do= need the meaning you want, you can introduce a non-member function templat= e only for smart pointers having such property, with a clearer, unambiguous= name, e.g. `change_owning`, rather than `reset`.


=C2=A0
=
That's all.

-

No= w lets look at release, which has also=C2=A0a=C2=A0different problem.
=

std::unique_ptr::release
std::shared_lock::release
std::unique_lock::release
std::pmr::monotonic_buffer_resource::release
std::pmr::unsynchronized_pool_resource::= release


What is common b/w these al= l?

They all give up a resource, which affects oth= er objects in the system.

In general, right now, w= hen you see release() in code, something quite important, worth noting is h= appening.
Something possibly requiring some other actions to tak= e care of.

None of these are=C2=A0trivial operatio= n.

observer_ptr makes it trivial.
It m= akes it only about itself, it does not affect other objects and stat= e.

Ok, for you it might not be a problem.

I only argue, it might well be - release() statement in co= de=C2=A0loses from its importance.

The importan= t uses of release() will be accompanied of trivial uses of it.
Not a good thing.

The problem= here is the name clashes within different use cases, whether taking observ= er_ptr into account or not. You have to do further (on the returned value f= rom the smart pointers' `release()`) to make them similar, that's a= lready somewhat awful (error-prone) if both styles are used in the same cod= ebase.

I do want to "detach" smart pointers or locks. But = for backward compatibility, perhaps it is easier to rename the latter ones.=

=C2=A0

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/a17356b2-2545-444a-9db5-98c36d90c6f4= %40isocpp.org.
------=_Part_23_1012790129.1476869910284-- ------=_Part_22_1099345371.1476869910284-- .