220 28956 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: Tue, 18 Oct 2016 19:19:36 -0700 (PDT) Lines: 301 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10_677072121.1476843576524" X-Trace: blaine.gmane.org 1476843595 2708 195.159.176.226 (19 Oct 2016 02:19:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 02:19:55 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBOVQTPAAKGQEI6PN3LY@isocpp.org Wed Oct 19 04:19:51 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwgTi-0006wt-Ss for gclcip-std-proposals@m.gmane.org; Wed, 19 Oct 2016 04:19:39 +0200 Original-Received: by mail-oi0-f71.google.com with SMTP id e200sf30833510oig.4 for ; Tue, 18 Oct 2016 19:19:41 -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=+7a2BM4U1RYu24EvUOPxcL1JPaT3N829FqJT+d23RZ0=; b=ri6gfCI54UOWMJBaqFbDh9hPXRJ7xLWsbV1xmpTgk90T6vBPIffClFFCXRZDnVzlE7 z+ooiMr9Yv8WHLvj5Pj0BuMyHhrbSu70+JqkWbbooQq/XYH+8Vp9akr9Bv9Gf5Rk1LSA LijvMwctCOLFG/IayaN99GPAR3jqNRzkvxZq+N5miBVSpqiqBk+Y6zNNQz+JaKeQN4Kk 8ynmd54qWGMsy7awTJdusEC8Tv9mRrQYk1IUwd6fTQf0h02H59471g7xyp3R9mBh90Ek 53IBp6sNULA7OGv+cPbmvp+nCsgOIaSIVivHfPxA63mgDFlNESFwbuAXd9Tl1fPlA+gR otVg== 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=+7a2BM4U1RYu24EvUOPxcL1JPaT3N829FqJT+d23RZ0=; b=UeY2A4a/dxWCkIz49DHg0Oqe3ZRhLlJwsHu+7380TBuaE/Z5BZqSercTil4ksT02Ou cVxI4hGE6NPAI5N4TEfKyIG27lCtlBMdT2MbhfRMDgh9JFkz93jYc7QvbHaCQsPzxPlo 1VG7n4dQPOWYFLKT5F3RLsDCPHpO/CGA/6nUFMPLKCq/jlpJ93RMxUa1Nm1bdLiNy7f2 IGEVcktqKOIrOGKPW1iu361n546BO3FwKx1wQh5hx9OhMCHC5YF8c4j4jBaRNKzMTNtu W2eFvp7xFHaCyxzILI6dZzwT+1qBkCKm7y4YZX4Vsj3cUgBiterHkQTRRTKofxjiagfj wGMg== 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=+7a2BM4U1RYu24EvUOPxcL1JPaT3N829FqJT+d23RZ0=; b=P1a5g5i42ZRP70Y1DMZn0Br6Ejwz2T7a7CEedYzWL0FOy2V96Afn4wJ/GP+bbgtSbJ P6m28dkET/2nlf2+MlkCeSH1azM4ryM7ewbD5Vug6a6IdJKZhMzdfPxZg1PzqALkH6j9 k01l0/s7k9nPThreRc/2hXU+mE/AoJ3hljur17xhevA4cE9rLY+imUfj5pT31/03Tow8 7KDnVAUPZyyWQjIpb+D/NfQKvegn86ZBZIxsArelpIch/K3VKzo4lGhsXJAvlZXXmqfr Si5AVImIuuOHTH8Excyg58BGYNBuNgTiYuJVBEZPlmouskT4qNu4LVc1Clbihg/GUjrw LT2A== X-Gm-Message-State: AA6/9RnJPG2fg0mFo4vJKfSJ8pSSPIF8bvk+uUcbpGR42Dr1YRiguVyKHrdzrtFdu3Ifvw== X-Received: by 10.157.22.237 with SMTP id s42mr845649ots.32.1476843580822; Tue, 18 Oct 2016 19:19:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.131.135 with SMTP id n7ls401738ioi.50.gmail; Tue, 18 Oct 2016 19:19:38 -0700 (PDT) X-Received: by 10.36.185.91 with SMTP id k27mr943865iti.6.1476843578042; Tue, 18 Oct 2016 19:19:38 -0700 (PDT) In-Reply-To: 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:28956 Archived-At: ------=_Part_10_677072121.1476843576524 Content-Type: multipart/alternative; boundary="----=_Part_11_56106407.1476843576524" ------=_Part_11_56106407.1476843576524 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=8A=E5=8D=885:37:57=EF=BC=8Cmihailn...@gmail.com=E5=86=99=E9=81=93= =EF=BC=9A > > > >>> By calling `reset`, you are making a contract with the smart pointer.= =20 >>> From that point forward, you will not do anything to access the object= =20 >>> referenced by that smart pointer, nor any object who's lifetime depends= on=20 >>> it, *unless* you have a guarantee from some other object. That is, as= =20 >>> far as this particular smart pointer is concerned, it is not going to= =20 >>> ensure anything. >>> >> > reset purpose is to re-set the smart pointer to a new value.=20 > > reset always, to this point, controls the deleter call - *one way or=20 > another* (right away call, pointer dtor call, use_count etc, etc does not= =20 > matter).=20 > This is what a smart pointer ensures, this is what is designed for. =20 > > The name `reset` is not only used on smart pointers. Literally, it has=20 nothing to do with lifetime of *other *objects. The additional meaning is= =20 granted by the class type. =20 > Same with release - touching it, means you are touch the deleter call,=20 > when and if it runs. =20 > > So, right now and for many, many years, these *are* lifetime management= =20 > APIs.=20 > I agree `release` is a poor name here, it should have been `detach` or=20 something else to reduce confusion with genuine lifetime management. But for smart pointers, it is not about lifetime management. Smart pointers= =20 are even not necessarily involved with controlling the lifetime. =20 > >> >>> `release` isn't even a function that most smart pointers have. >>> >>> observer_ptr pretends to be smart with risk of being harmful and/or=20 >>> confusing.=20 >>> >> >> To whom is it harmful or confusing? Are you actually trying to claim tha= t=20 >> someone is going to assume that a smart pointer with the word "observer"= in=20 >> it is going to manage memory? >> > > O, yes I do. The moment a lib typedefs these, you are left to wonder=20 > what's up with all those reset-s and release-s. > > And what about *auto*? The explicit type is less and less visible in=20 > modern code. > > *Even if* not typedefed, even if you learn the types, you will have to=20 > constantly remind yourself, "is this is observer or is it not". > > You look a function and an observer is used. > Then you switch to another function, you see exactly the same code, but= =20 > this time it is not an observer and you forgot to look up the type.=20 > You spend 10 min consuming the code in the wrong way, thinking it does on= e=20 > thing, but it does something different. > > This has the exact same problem as if one overloads a smart=20 > pointer operator=3D on the managed type.=20 > > Two completely different actions (pointer copy and deleter management) ar= e=20 > expressed by visually the same code.=20 > Sure, the type is different, but in this case this is not enough - you=20 > better use different language for different things. > > reset is that different language. > > You misread what is "smart". It is "smart" because as a designer of the interface, you can attach=20 intended additional behavior to something already like pointers. That's=20 all. No magic about lifetime management is guaranteed existed; it is up to= =20 the designer of the API. =20 > >> Anyone who does that *deserves* what they get. >> >> The point of `observer_ptr` is to represent when a function is being=20 >> given a pointer it does not have ownership of. >> > > As commented, raw pointers are left for that use, and that use only. No= =20 > confusion if owner<> is used instead. No overloading of operations. No ne= w=20 > concepts. > > And BTW owner<> is better, because it signals the *unordinary* (in modern= =20 > code) case, it is labeled, because* it is special*.=20 > Raw pointer is *not labeled*, he is *not special*.=20 > Raw pointer is simply ill-designed in aspect of the need of a=20 general-purposed language. It is essentially a kind of the sum type of=20 random access iterators and non-owning smart pointer types. The rest thing= =20 it provides is the ease of binary interops, which is a kind of leaked=20 abstraction from the underlying implementation, and not guaranteed to work= =20 even in the current language design. Explicit address types may be better= =20 for the last task. The sin of raw pointer is, it is *too special*. It has coupled many=20 unrelated functionalities (as portable abstraction) as a bundle in the core= =20 language (as well polluting the binary interface continuously). To label it= =20 to get the right functionality is in the sorts of workaround, not the fix,= =20 even this approach can easily play well with modern language=20 implementations. So there should be a place for the nominal (named)=20 non-owning pointer in a right interface design. Another thing to be noted: you should normally fix the ownership=20 requirements statically during the design of API, and labeling some=20 non-owning pointers to change them as owning ones is essentially risky and= =20 difficult to do correctly. Even you have to do so, `owner<>` is not=20 necessarily better. Anyway, to patch it with `owner<>` or convert it to=20 some owning pointer types to express ownership is the further step, based= =20 on the fact that you have already precisely expressed non-onwership - and= =20 raw pointer is not the correct type at the first place. =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/c651cc1b-e3f6-4779-94eb-79749d8a25f8%40isocpp.or= g. ------=_Part_11_56106407.1476843576524 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=8A=E5=8D=885:37:57=EF=BC=8Cmihailn...@= gmail.com=E5=86=99=E9=81=93=EF=BC=9A


By ca= lling `reset`, you are making a contract with the smart pointer. From that = point forward, you will not do anything to access the object referenced by = that smart pointer, nor any object who's lifetime depends on it, unl= ess you have a guarantee from some other object. That is, as far as thi= s particular smart pointer is concerned, it is not going to ensure anything= ..

reset purpos= e is to re-set the smart pointer to a new value.

= reset always, to=C2=A0this=C2=A0point, controls the deleter call - one w= ay or another (right away call, pointer dtor call, use_count etc, etc= =C2=A0does not matter).
This is=C2=A0what a smart pointer ensure= s, this is what is designed for.=C2=A0=C2=A0

The name `reset` is not only used on smart pointers. Literall= y, it has nothing to do with lifetime of other objects. The addition= al meaning is granted by the class type.
=C2=A0
Same with re= lease - touching it, means you are=C2=A0touch the deleter call, when and if= it runs. =C2=A0

So, right now and for many, many = years, these are lifetime management APIs.

I agree `release` is a poor name here, it should ha= ve been `detach` or something else to reduce confusion with genuine lifetim= e management.

But for smart pointers, it is not about lifetime manag= ement. Smart pointers are even not necessarily involved with controlling th= e lifetime.

=C2=A0

`re= lease` isn't even a function that most smart pointers have.

observer_ptr pretends to be smart with risk of being harmful a= nd/or confusing.

To whom is i= t harmful or confusing? Are you actually trying to claim that someone is go= ing to assume that a smart pointer with the word "observer" in it= is going to manage memory?

O, yes I do. The moment a lib typedefs these, you are left to wonder what&= #39;s up with all those reset-s and release-s.

And= what about auto? The explicit=C2=A0 type is less and less visible i= n modern code.

Even if not typedefed, even = if you learn the types, you will have to constantly remind yourself, "= is this is observer or is it not".

You look a= function and=C2=A0an observer is used.
Then you switch to anothe= r function, you see exactly the same code, but this time it is not an obser= ver and you forgot to look up the type.
You spend 10 min consumi= ng the code in the wrong way, thinking it does one thing, but it does somet= hing different.

This has the exact same problem as= if one overloads a smart pointer=C2=A0operator=3D on the managed=C2=A0type= ..

Two completely different actions (pointer copy = and deleter management)=C2=A0are expressed by visually=C2=A0the same code. =
Sure, the type=C2=A0is different, but in this case this is not e= nough - you better use different language for different things.
<= br>
reset=C2=A0is that different language.

You misread what is "smart".

It is &= quot;smart" because as a designer of the interface, you can attach int= ended additional behavior to something already like pointers. That's al= l. No magic about lifetime management is guaranteed existed; it is up to th= e designer of the API.
=C2=A0

Anyone who does that deserves= what they get.

The point of `observer_ptr` is to represent when= a function is being given a pointer it does not have ownership of.

As commented, raw pointers are lef= t for that use, and that use=C2=A0only. No confusion if owner<> is us= ed instead. No overloading of operations. No new concepts.

And BTW owner<> is better, because it signals the unordin= ary (in modern code) case,=C2=A0it is labeled, because it is special= .
Raw pointer is not labeled, he is not special.
Raw pointer is simply ill-designed in aspe= ct of the need of a general-purposed language. It is essentially a kind of = the sum type of random access iterators and non-owning smart pointer types.= The rest thing it provides is the ease of binary interops, which is a kind= of leaked abstraction from the underlying implementation, and not guarante= ed to work even in the current language design. Explicit address types may = be better for the last task.

The sin of raw pointer is, it is too= special. It has coupled many unrelated functionalities (as portable ab= straction) as a bundle in the core language (as well polluting the binary i= nterface continuously). To label it to get the right functionality is in th= e sorts of workaround, not the fix, even this approach can easily play well= with modern language implementations. So there should be a place for the n= ominal (named) non-owning pointer in a right interface design.

Anoth= er thing to be noted: you should normally fix the ownership requirements st= atically during the design of API, and labeling some non-owning pointers to= change them as owning ones is essentially risky and difficult to do correc= tly. Even you have to do so, `owner<>` is not necessarily better. Any= way, to patch it with `owner<>` or convert it to some owning pointer = types to express ownership is the further step, based on the fact that you = have already precisely expressed non-onwership - and raw pointer is not the= correct type at the first place.


=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/c651cc1b-e3f6-4779-94eb-79749d8a25f8= %40isocpp.org.
------=_Part_11_56106407.1476843576524-- ------=_Part_10_677072121.1476843576524-- .