220 28939 article Path: news.gmane.org!.POSTED!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Is World's Dumbest Pointer still on the table?!? Date: Tue, 18 Oct 2016 10:40:44 -0400 Lines: 160 Approved: news@gmane.org Message-ID: References: <8a6731f7-1c9b-482d-817e-c2374fc9ae1b@isocpp.org> <7d817482-e7c3-4724-9501-738d4c9083d7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114423427d5aed053f24ad82 X-Trace: blaine.gmane.org 1476801670 27107 195.159.176.226 (18 Oct 2016 14:41:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 14:41:10 +0000 (UTC) To: Standard Proposals Original-X-From: std-proposals+bncBCUZ5QWKNQIO52EYYACRUBBWPTVMU@isocpp.org Tue Oct 18 16:41:05 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwVZN-0004GQ-BH for gclcip-std-proposals@m.gmane.org; Tue, 18 Oct 2016 16:40:45 +0200 Original-Received: by mail-vk0-f72.google.com with SMTP id t22sf163262222vkb.7 for ; Tue, 18 Oct 2016 07:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=YKyF++qCrzFfzGCNJGB2KJMF6uK4UJxki1O2B92e1+g=; b=nherG8+zKydd2Niuv3dQN0L/S5od/RiAPebdHzmvzBlqIkJy0IRKyOZaiiBpoUsqBM 8oebYbXDyNVzBwNV+Pw0DMGFr6Imr+5GYhKLbNYLChWotAPSBvR3QQLchIrIz4bq/61G DjgRZyitjbVk01GjMO526C9c/duYxeOIKz4kFYNeJrZPGncG6LvbBshaHwHsrJUudAOX qJvt8byL1+CyBF9Ay1EtHFXcQft7mRWxsmtB+qpBWPOLI0NrW572N4+OLYFYCrYb/AOf EPqvv9vUwTNXW3qg7R7NqG57fMT2L6v4aNV1TEsjOoOkKLVk5tsV3ObDnB1Zl9edvmHZ lD5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=YKyF++qCrzFfzGCNJGB2KJMF6uK4UJxki1O2B92e1+g=; b=jMkn3SG/Yrq8twcvFLO20N1Ct4D4Aoo990MQgcd4SqmzkX7JNRq1GqVgeRWZMgnIQ7 tDiEp7XeWqNd61SqlOIhdvX4QdMXhm3nDB/Pl7wg9S9+csimnVg4zI6l92t15QJpLlc6 fwanAPQhkamna+YMGXUfo4/vnnPo44a566mIYCf6bNcOS7FrHYvDIbJBVwC7UiiFXkrU Un6LfSmlax5YjZ1HgHH3eqg3Wl2fLwfrcUFm+mLED+b/X+MMUm1BC2MiJDksqVM/ljkf F3bc6EvD0pJ0BI7WtFQbcMPJZCuqoNDZXLLIgR8VQsIac3wtzsNm7mi8ba0+OCKj5iLv 5FtA== X-Gm-Message-State: AA6/9RkEINvrmUQrGlId18iXNpO2g59+TwTNfWUIGgVi2R4+7Ao6R9CMhMQOvzmon7D4XA== X-Received: by 10.31.61.210 with SMTP id k201mr262662vka.0.1476801647293; Tue, 18 Oct 2016 07:40:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.41.69 with SMTP id d63ls5266757otb.48.gmail; Tue, 18 Oct 2016 07:40:46 -0700 (PDT) X-Received: by 10.31.96.6 with SMTP id u6mr850468vkb.53.1476801646368; Tue, 18 Oct 2016 07:40:46 -0700 (PDT) Original-Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com. [2607:f8b0:4002:c05::22d]) by mx.google.com with ESMTPS id g79si2385517vkf.22.2016.10.18.07.40.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 07:40:46 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4002:c05::22d as permitted sender) client-ip=2607:f8b0:4002:c05::22d; Original-Received: by mail-yw0-x22d.google.com with SMTP id t193so140372435ywc.2 for ; Tue, 18 Oct 2016 07:40:46 -0700 (PDT) X-Received: by 10.28.6.137 with SMTP id 131mr11785123wmg.49.1476801645597; Tue, 18 Oct 2016 07:40:45 -0700 (PDT) Original-Received: by 10.28.157.23 with HTTP; Tue, 18 Oct 2016 07:40:44 -0700 (PDT) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4002:c05::22d as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:28939 Archived-At: --001a114423427d5aed053f24ad82 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 18, 2016 at 9:44 AM, wrote: > > > On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Ville Voutilainen wrote: >> >> On 18 October 2016 at 16:08, wrote: >> > In any case, for a smart pointer, reset and release are lifetime >> management >> > interfaces. >> > >> > observer_ptr changes this. >> >> But yet its users are unlikely to find this a problem, because some of >> them don't consider >> reset and release to be lifetime management interfaces. >> > > reset and release is lifetime interface in the context of a smart pointer > - if you touch these, the lifetime of the object will change. > That's a fact, not a point a view. > release() doesn't change the object's lifetime for unique_ptr - it hands the pointer back to you, still alive. It does change the ownership. It maybe should have been called detach(), if we wanted to have a distinction here. shared_ptr doesn't have a release(). unique_ptr's release appears to be an evolution of auto_ptr's. Which also "detached" - std::auto_ptr::release - std::unique_ptr::release - std::shared_lock::release - std::unique_lock::release - std::pmr::monotonic_buffer_resource::release - std::pmr::unsynchronized_pool_resource::release The first 4 "detach" - ie break the association, without changing the underlying object lifetime/state/refcount The last 2 actually release the memory. This is unfortunate deviation of the word "release", maybe the last 2 should be changed? Outside the standard, release() usually means free() or decr-refcount etc, so auto_ptr didn't set a precedent outside the standard unfortunately :-( (There's also memory_order_release but I think the context there is different enough to not cause confusion) -- Be seeing you, Tony -- 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/CAOHCbiskO5DpTwym8nH%3Dyra%2BYpa-%2Bb-ycfSV%2B34JLjPqC8ST4g%40mail.gmail.com. --001a114423427d5aed053f24ad82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 18, 2016 at 9:44 AM, <mihailnajdenov@gmail.com= > wrote:


On Tuesday, October 18, 2016 at 4:17:29 PM UTC+3, Vil= le Voutilainen wrote:
On 18 October 2016 at 16:08, =C2=A0<mihailn...@gmail.com> wrote:
> In any case, for a smart pointer, reset and release are lifetime m= anagement
> interfaces.
>
> observer_ptr changes this.

But yet its users are unlikely to find this a problem, because some of
them don't consider
reset and release to be lifetime management interfaces.

reset and release is lifetime i= nterface in the context of a smart pointer -=C2=A0 if you touch these, the = lifetime of the object will change.
That's a fact,=C2=A0not = a point a view.

release() doesn= 't change the object's lifetime for unique_ptr - it hands the point= er back to you, still alive.=C2=A0 It does change the ownership. It maybe s= hould have been called detach(), if we wanted to have a distinction here.= =C2=A0 shared_ptr doesn't have a release().

unique= _ptr's release appears to be an evolution of auto_ptr's.=C2=A0 Whic= h also "detached"

  • std::unique_ptr::release
  • std::shared_lock::release
  • std::unique_lock::release


    • The first 4 "detach" - ie break the assoc= iation, without changing the underlying object lifetime/state/refcount

    T= he last 2 actually release the memory.

    This is= unfortunate deviation of the word "release", maybe the last 2 sh= ould be changed?

    Outside the standard, release() usually means free(= ) or decr-refcount etc, so auto_ptr didn't set a precedent outside the = standard unfortunately :-(


    (There's also memory_o= rder_release but I think the context there is different enough to not cause= confusion)


    --
    Be seeing you,
    Tony

    --
    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/CAOHCbisk= O5DpTwym8nH%3Dyra%2BYpa-%2Bb-ycfSV%2B34JLjPqC8ST4g%40mail.gmail.com. --001a114423427d5aed053f24ad82-- .