220 28953 <5adf05e5-edb4-4706-816b-59b71d5c1a6f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Is World's Dumbest Pointer still on the table?!? Date: Tue, 18 Oct 2016 15:31:13 -0700 (PDT) Lines: 349 Approved: news@gmane.org Message-ID: <5adf05e5-edb4-4706-816b-59b71d5c1a6f@isocpp.org> 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_534_625940248.1476829874016" X-Trace: blaine.gmane.org 1476829891 2965 195.159.176.226 (18 Oct 2016 22:31:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 22:31:31 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBNGFTLAAKGQESROMZFA@isocpp.org Wed Oct 19 00:31:26 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwcuh-00070b-5S for gclcip-std-proposals@m.gmane.org; Wed, 19 Oct 2016 00:31:15 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id d132sf17804308oib.3 for ; Tue, 18 Oct 2016 15:31:17 -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=o6bsbnPHMYjulCJ+dPpBeMymAv8VzXh8+YHG7uWSxo0=; b=YDFVV/bdA6P9ZrNIvNtcemeDQO8juqUjJyd51CAomulKI7nLGWvbiFyYW4ZM6PvU95 1ZSC5afNbH/LhdmvGVrwBBb0oGikVyq5FUhGqm3Qh5ubWwN4yXaB5z0iZOECHYw+lnUo i4DsGoa50qyFBbKL3rphZw/O69N1x78LUpRqXjAKu76I0NibsZIu2LGeL5dJuZpubqMS ugPLzPmq4P/qJSqymrn4r+nSCI7NqSohqakDy4TNG7DCMnXwRvOXnB/lTE2xPa90mrPU XSrjvqMeL4ErWFCwacYQ8qgSFvmQC5bx/lbf7Mjg81LsToH4vqSMFgfwF30EtNqeIwMg CtjA== 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=o6bsbnPHMYjulCJ+dPpBeMymAv8VzXh8+YHG7uWSxo0=; b=0mJIUBlP4fWjQcLDdtsp8B9b0zzHkkrXbfn5z77DPr9VG2+XfEt4qbSNr2YclaZKel PS9M4X32xN5243J7qCfB6qGJtH1be4sF6tfZVvXMIV52sCTJXa16kwaX4VO9sXgHTEre yhi8DKA/EZV8OCqK7z6Uy7D1ABebR1Ni+rQ+kzizz2WKNHZdUQL+pQG0NM7XimpT11y7 XWTP0thmevEI/f5ccXIdx+CcdzoWl0lGpFxbPWEmKkY4c/LuByoaL+b91WTyZwHdq3Ag SocshenNRJkb9wrMfWJ3VRvRSu9KIkDFAVVQ4DX0vlYJLyUqgUdSZhXSbPHq59PXKNtv /gyw== 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=o6bsbnPHMYjulCJ+dPpBeMymAv8VzXh8+YHG7uWSxo0=; b=b1OvFpcxP6wfiu/kC9p4CW8n3/7xg02O+aC7vHHYbS3jWNvi4V36Ik8SCeMEu/p0Ct QljpoMrIpEAvFk06Ao4cBr94sx3BewtPGAu+ayGSnEjzvxGTWAWs8rbSm1Zb1cccscka nXDD2kx3d8XkAEjdPTruZcBNPefznIyheCxFQhcpJTGDySh+GnFROqgj4/PMK00M1rwz IQWDVABM4gGDbXUGSn8WeLfc6PWC+oZljyVn3bLREjA3BroLp8fy1uPAccWqz2xKcjYT xYdrPz3w1zH0mI0L0LHdGKgOBSkLTGcDFrOu/Fq7n4xs67L1dZxw60YuDY7C7tHhAt8+ tXWg== X-Gm-Message-State: AA6/9Rmq8hKgtW3wpg2Igv2wuqc09BpH+DR7A3WAC1ojq4wEN8jOlieTcFm5C8Pbc6XrEg== X-Received: by 10.157.26.80 with SMTP id u16mr953167otu.44.1476829877222; Tue, 18 Oct 2016 15:31:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.34.148 with SMTP id i142ls363108ioi.7.gmail; Tue, 18 Oct 2016 15:31:16 -0700 (PDT) X-Received: by 10.36.115.203 with SMTP id y194mr906233itb.0.1476829876086; Tue, 18 Oct 2016 15:31:16 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:28953 Archived-At: ------=_Part_534_625940248.1476829874016 Content-Type: multipart/alternative; boundary="----=_Part_535_1547406836.1476829874016" ------=_Part_535_1547406836.1476829874016 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 18, 2016 at 5:37:57 PM UTC-4, mihailn...@gmail.com wrote: > > On Tuesday, October 18, 2016 at 11:09:48 PM UTC+3, Nicol Bolas wrote: >> >> On Tuesday, October 18, 2016 at 9:44:40 AM UTC-4, mihailn...@gmail.com >> wrote: >>> >>> ... >>> No, it is a point of view. >>> >>> To hold onto a smart pointer object means that you expect the object >>> pointed to by the smart pointer to continue to exist, pursuant to the smart >>> pointer's contract. A `weak_ptr` does not ensure the lifetime of the >>> pointed-to object. What it does ensure is that, if that lifetime has ended, >>> you'll know about it. You may get a NULL pointer, but you'll never get an >>> invalid one. >>> >>> When you `reset` a smart pointer, you are saying that you no longer >>> expect that object to exist. Whether or not it is actually destoryed is >>> smart-pointer specific. `shared_ptr::reset` doesn't guarantee the object >>> will be destroyed. `weak_ptr::reset` doesn't destroy anything at all. >>> >> > reset on a waek_ptr does not take a pointer! It does not overload the > meaning of reset! > `reset` on all pointer types doesn't have to be given a pointer. The parameter is optional; if you pass nothing, then the value of the pointer becomes NULL. By calling `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, *unless* you have a guarantee from some other object. That is, as >>> far as this particular smart pointer is concerned, it is not going to >>> ensure anything. >>> >> > reset purpose is to re-set the smart pointer to a new value. > And in so doing, you can no longer use the old value. Consider the following. auto *ptr = smart_ptr_from_somewhere.get(); smart_ptr_from_somewhere.reset(); ptr->stuff(); Is this reasonable code? Regardless of the type of `smart_ptr_from_somewhere`, I submit that it is *not reasonable*. It may work, depending on the exact type of the smart pointer. But it is never reasonable code. If the smart pointer is `shared_ptr`, it might work. It might not. If the smart pointer is an `observer_ptr`, then it will work. If the smart pointer is a `unique_ptr`, it will almost certainly not work. But regardless of whether it "works", doing this is a violation of the idea of resetting a smart pointer. By resetting one, you are releasing your hold over that object. Whether that *actually* destroys the object or not is essentially irrelevant. You are saying that you can no longer access a resource through a particular pointer anymore. And therefore, the smart pointer is free to do any cleanup. Or not do any, whatever the case may be. Your point of view is founded on what the code is actually doing. My point of view is founded in what it means *conceptually*. And that's really what a reader of this code cares about. `reset` means that the user isn't going to use it anymore, not "delete this right now". If the above code were submitted to code review, I would say that the reader should reject it *regardless* of what kind of smart pointer it is. The reader should not look up the pointer type, and check various other things to see if the object is live or some such. The problem is not that the code might be broken. The problem is that the code *always* doesn't make sense. > Same with release - touching it, means you are touch the deleter call, > when and if it runs. > No. `unique_ptr::release` means that you are now in control of, and therefore assume the responsibility of, releasing the resource managed by the object. Now, I agree that `observer_ptr` should not have such a function. But only because it conceptually makes no more sense for an `observer_ptr` to be able to release the pointer than it does for a `shared_ptr` to do so. It cannot release ownership that it does not possess. `release` isn't even a function that most smart pointers have. >>> >>> observer_ptr pretends to be smart with risk of being harmful and/or >>> confusing. >>> >> >> To whom is it harmful or confusing? Are you actually trying to claim that >> someone is going 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's up with all those reset-s and release-s. > Even if I agree that `reset` on an observer_ptr creates confusion, I submit that this confusion will be highly localized. Why? Because at the end of the day, `reset` is not a commonly used function. Really, how many times have you actually `reset` a smart pointer object explicitly? Usually, you copy/move into them, typically from `make_unique/shared` or with some other pointer you've been given. The most common use is to create them on the stack/as member variables, initialize them, and let the scope/destructor clean them up. Oh sure, `reset` happens. But it's hardly the most common usage of smart pointers. So I won't be wondering about "all those" calls to a rarely used function. > You look a function and an observer is used. > Then you switch to another function, you see exactly the same code, but > this time it is not an observer and you forgot to look up the type. > You spend 10 min consuming the code in the wrong way, thinking it does one > thing, but it does something different. > It's no more different than wondering if `shared_ptr::reset` is destroying the object or not. This has the exact same problem as if one overloads a smart > pointer operator= on the managed type. > No, it does not. That is about preventing the implicit adopting and managing a pointer which was not meant to be managed. It has nothing to do with the implicit ending of the management of the existing object. 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 left for that use, and that use only. > You declared this, but with no proof. Yes, the C++ core guidelines lays this out, but they are *not* the Gods of All C++ Programming. They are not a Holy Text brought down from the mountain top. They are not divinely inspired wisdom. They're just a set of rules. While I certainly prefer their use of raw pointers, if someone else has a different use, that's up to them and their codebase. I lack the arrogance to declare that they are *wrong* to want to go a different way. -- 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 email 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/5adf05e5-edb4-4706-816b-59b71d5c1a6f%40isocpp.org. ------=_Part_535_1547406836.1476829874016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, October 18, 2016 at 5:37:57 PM UTC-4, mihailn.= ...@gmail.com wrote:
On Tuesday, October 18, 2016 at 11:09:48 PM UTC+3, Nicol Bolas wrote:=
On Tuesday, Octobe= r 18, 2016 at 9:44:40 AM UTC-4, mihailn...@gmail.com wrote:
...
No, it is a point of= view.

To hold onto a smart pointer object means that you expect the= object pointed to by the smart pointer to continue to exist, pursuant to t= he smart pointer's contract. A `weak_ptr` does not ensure the lifetime = of the pointed-to object. What it does ensure is that, if that lifetime has= ended, you'll know about it. You may get a NULL pointer, but you'l= l never get an invalid one.

When you `reset` a smart pointer, you ar= e saying that you no longer expect that object to exist. Whether or not it = is actually destoryed is smart-pointer specific. `shared_ptr::reset` doesn&= #39;t guarantee the object will be destroyed. `weak_ptr::reset` doesn't= destroy anything at all.
reset on a waek_ptr does not take a pointer! It does not o= verload the meaning of reset!

`reset= ` on all pointer types doesn't have to be given a pointer. The paramete= r is optional; if you pass nothing, then the value of the pointer becomes N= ULL.

By callin= g `reset`, you are making a contract with the smart pointer. From that poin= t forward, you will not do anything to access the object referenced by that= smart pointer, nor any object who's lifetime depends on it, unless<= /i> you have a guarantee from some other object. That is, as far as this pa= rticular smart pointer is concerned, it is not going to ensure anything.

reset purpose is= to re-set the smart pointer to a new value.
<= br>And in so doing, you can no longer use the old value.

Consider th= e following.

<= div class=3D"subprettyprint">auto *ptr <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D smart_ptr_from_somewhere= .get();
smart_ptr_from_somewhere.reset();
ptr->stuff();

Is this reasona= ble code? Regardless of the type of `smart_ptr_from_somewhere`, I submit th= at it is not reasonable. It may work, depending on the exact type of= the smart pointer. But it is never reasonable code.

If the smart po= inter is `shared_ptr`, it might work. It might not. If the smart pointer is= an `observer_ptr`, then it will work. If the smart pointer is a `unique_pt= r`, it will almost certainly not work.

But regardless of whether it = "works", doing this is a violation of the idea of resetting a sma= rt pointer. By resetting one, you are releasing your hold over that object.= Whether that actually destroys the object or not is essentially irr= elevant. You are saying that you can no longer access a resource through a = particular pointer anymore. And therefore, the smart pointer is free to do = any cleanup. Or not do any, whatever the case may be.

Your point of = view is founded on what the code is actually doing. My point of view is fou= nded in what it means conceptually. And that's really what a rea= der of this code cares about. `reset` means that the user isn't going t= o use it anymore, not "delete this right now".

If the abov= e code were submitted to code review, I would say that the reader should re= ject it regardless of what kind of smart pointer it is. The reader s= hould not look up the pointer type, and check various other things to see i= f the object is live or some such.

The problem is not that the code = might be broken. The problem is that the code always doesn't mak= e sense.
=C2=A0
Same with release - touching it, means you are= =C2=A0touch the deleter call, when and if it runs. =C2=A0

No. `unique_ptr::release` means that you are now in control= of, and therefore assume the responsibility of, releasing the resource man= aged by the object.

Now, I agree that `observer_ptr` should not have= such a function. But only because it conceptually makes no more sense for = an `observer_ptr` to be able to release the pointer than it does for a `sha= red_ptr` to do so. It cannot release ownership that it does not possess.
`release` isn= 9;t even a function that most smart pointers have.

= observer_ptr pretends to be smart with risk of being harmful and/or confusi= ng.

To whom is it harmful or = confusing? Are you actually trying to claim that someone is going 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's up with= all those reset-s and release-s.

Even if = I agree that `reset` on an observer_ptr creates confusion, I submit that th= is confusion will be highly localized. Why?

Because at the end of th= e day, `reset` is not a commonly used function.

Really, how many tim= es have you actually `reset` a smart pointer object explicitly? Usually, yo= u copy/move into them, typically from `make_unique/shared` or with some oth= er pointer you've been given. The most common use is to create them on = the stack/as member variables, initialize them, and let the scope/destructo= r clean them up.

Oh sure, `reset` happens. But it's hardly the m= ost common usage of smart pointers. So I won't be wondering about "= ;all those" calls to a rarely used function.
=C2=A0
Yo= u look a function and=C2=A0an observer is used.
Then you switch t= o another function, you see exactly the same code, but this time it is not = an observer and you forgot to look up the type.
You spend 10 min consuming the code in the wrong way, thinking it does one= thing, but it does something different.

I= t's no more different than wondering if `shared_ptr::reset` is destroyi= ng the object or not.

This has the exact same problem as i= f one overloads a smart pointer=C2=A0operator=3D on the managed=C2=A0type.<= /div>

No, it does not. That is about preventing = the implicit adopting and managing a pointer which was not meant to be mana= ged. It has nothing to do with the implicit ending of the management of the= existing object.

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 left for that use,= and that use=C2=A0only.

You declared this= , but with no proof. Yes, the C++ core guidelines lays this out, but they a= re not the Gods of All C++ Programming. They are not a Holy Text bro= ught down from the mountain top. They are not divinely inspired wisdom. The= y're just a set of rules.

While I certainly prefer their use of = raw pointers, if someone else has a different use, that's up to them an= d their codebase. I lack the arrogance to declare that they are wrong to want to go a different way.

--
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/5adf05e5-edb4-4706-816b-59b71d5c1a6f= %40isocpp.org.
------=_Part_535_1547406836.1476829874016-- ------=_Part_534_625940248.1476829874016-- .