220 28959 <3241f484-0d5a-4363-8ddd-d3813a54fcb1@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Is World's Dumbest Pointer still on the table?!? Date: Wed, 19 Oct 2016 01:30:36 -0700 (PDT) Lines: 148 Approved: news@gmane.org Message-ID: <3241f484-0d5a-4363-8ddd-d3813a54fcb1@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_70_1977316828.1476865836979" X-Trace: blaine.gmane.org 1476865883 12923 195.159.176.226 (19 Oct 2016 08:31:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 08:31:23 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBLW6TTAAKGQETTJ5AUA@isocpp.org Wed Oct 19 10:31:15 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 1bwmGk-0006bW-PG for gclcip-std-proposals@m.gmane.org; Wed, 19 Oct 2016 10:30:39 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id e200sf43453750oig.4 for ; Wed, 19 Oct 2016 01:30: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=ksWpyP62EtAxgheXUN9H067Np3bKGA5BvMxFAGVnJec=; b=oikkB/1/k4T6LbO6u+K+DXPvr4fjamhjS6llHGSZPGd0ENhufGW8vLB8gTLnrBXs/o thjCSbKwcUVkrKxzkFHJzwaRn4KlVshD91MvlWyC0aJuCJ0pF5hGYWLQK4z0Opk61zFv u9DDRE9vdWaLvys5zsMluY+k59M7GGmtT6yqN7EsPXddFMW+C3A1Ea0K0OFHbEw7Rt+9 APNM6pp6/EAbwUPjgsSWig9cbYHbegkFIzLF51wraUmJYjLKFy3Rt5cdcyXlYS/HPdAl BY9UZdGbT/CBeqtc7Jt895oTyCZG5ZkO79qpoMu+3Jd4EKBHD8S648tc3Zo4+BMJoHtS ZCCg== 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=ksWpyP62EtAxgheXUN9H067Np3bKGA5BvMxFAGVnJec=; b=FHt7RXTrU0S1JnfjaXO1FF8bqiDKTFmUmxaD+k2amTrpNvs39BfSteIVRjh0HYp85M tJRP88XraoBRupkISw8/yVwhI0MK8xsfKIiCznmPj71Vv3xCBTKT2vQ35ImICy8Q3ZXy F2kPChfUd/Md7uuT8NXRWi+rHH9p4XcPu+p+iASJfc8qlBhnYzJde0ii5FaOMrytRHgS UEaKmwZxyBLnkT5r3ckoUcYGcBFKKTnZuN6Jw3QNyLCMxNeaXyJutJXt1LEi6ERikpRf 2Q7vbRbaWYFFxhpboJybDIAbyYANaG4PRfxazFGFW31ju9zP9iNquZj4Dx6nBRSbKH6D oHhQ== 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=ksWpyP62EtAxgheXUN9H067Np3bKGA5BvMxFAGVnJec=; b=cqCX+CgaUh0uDTk8Q0S70YDuOntHgmJs0U9F262bQ2c33EDPqa0WtrVbg53lUFGfd+ wy0C4Kctc0Agtj8ZwgNSpjpweKHrOu/pTn2w4pdLrqZyu3nJTgRmOEsAvVQfAVOw9c0M 8ATYC27/AZMrMhi8lfyGC99qsWD43C4s4Ovxfq5+OhfmLxLbmNS/wxwaNDz52qP3O+T7 8LHSXpD5J3Dvge8b2crvs5ClBZ+fd83hSLkTNILTOIMrZe8/UOTAB9llbXaB+2EtNsCn 2dBRzRrfpKQelt/R3Y2MdmqeQbNa9JEsdusb4R0w3QLcNCPpjyp2jF/adjBwkS4PQrni 1iVg== X-Gm-Message-State: AA6/9RmFX6WiIUVbbp5lUxuYyzDdI4LjMyz7D+2EvrOp/sVy6bEEQG/H6LKKT0iAAI/EeA== X-Received: by 10.157.17.174 with SMTP id v43mr1546254otf.141.1476865840551; Wed, 19 Oct 2016 01:30:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.10.212 with SMTP id 81ls661904iok.25.gmail; Wed, 19 Oct 2016 01:30:38 -0700 (PDT) X-Received: by 10.36.181.92 with SMTP id j28mr427786iti.3.1476865838569; Wed, 19 Oct 2016 01:30:38 -0700 (PDT) In-Reply-To: <5adf05e5-edb4-4706-816b-59b71d5c1a6f@isocpp.org> X-Original-Sender: MihailNajdenov@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:28959 Archived-At: ------=_Part_70_1977316828.1476865836979 Content-Type: multipart/alternative; boundary="----=_Part_71_780092509.1476865836980" ------=_Part_71_780092509.1476865836980 Content-Type: text/plain; charset=UTF-8 Ok, I hope we all agree reset(T*) and 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 whatever meaning it wants to. I simply argue, it can well be a problem and potentially adding a confusion. auto p = foo(); if(cond(p)) p.reset(hello.getBar()); All I am saying, this code above, for current smart pointers, meant - p now *has* the bar object. With observer_ptr into the picture, it might also mean - p now *points to* a bar. There is some overloading, which I personally find unfortunate and not well justified. 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? 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 important, worth noting is happening. Something possibly requiring some other actions to take care of. None of these are trivial operation. observer_ptr makes it trivial. It makes it only about *itself*, it does not affect other objects and state. Ok, for you it might not be a problem. I only argue, it might well be - release() statement in code loses from its importance. *The important uses of release() will be accompanied of trivial uses of it.* Not a good thing. -- 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/3241f484-0d5a-4363-8ddd-d3813a54fcb1%40isocpp.org. ------=_Part_71_780092509.1476865836980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok,
I hope we all agree reset(T*) and rele= ase() have new meaning in the context of a observer_ptr. Ok?

=
For you, it is not a problem - the class is free to add whatever= 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 saying, this code above, for cu= rrent smart pointers, meant - p now has the bar object.
With observer_ptr into the picture, it might also mean - p now= points to a bar.

There is some=C2=A0overlo= ading, which I personally find unfortunate and not well justified.

That's all.

-

=
Now lets look at release, which has also=C2=A0a=C2=A0different p= roblem.

std::unique_ptr::release
std::shared_lo= ck::release
std::unique_lock::release
std::pmr::monoton= ic_buffer_resource::release
std::pmr::unsynchronized_pool_resourc= e::release


What is common b/w these= all?

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 important, worth noting i= s happening.
Something possibly requiring some other actions to = take care of.

None of these are=C2=A0trivial opera= tion.

observer_ptr makes it trivial.
I= t makes it only about itself, it does not affect other objects and s= tate.

Ok, for you it might not be a problem.
=

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

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


--
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/3241f484-0d5a-4363-8ddd-d3813a54fcb1= %40isocpp.org.
------=_Part_71_780092509.1476865836980-- ------=_Part_70_1977316828.1476865836979-- .