220 20784 <5604536F.3040207@gmail.com> article Path: news.gmane.org!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: optional_ptr - A smart pointer which optionally owns the resource Date: Thu, 24 Sep 2015 22:47:59 +0300 Lines: 84 Approved: news@gmane.org Message-ID: <5604536F.3040207@gmail.com> References: <7502c195-e5b9-4f04-8997-666933cef239@isocpp.org> <248df8cc-e763-4c30-89d6-d740ef31a3e2@isocpp.org> <05602720-a61c-4e39-8898-3f886c869efa@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1443124093 19714 80.91.229.3 (24 Sep 2015 19:48:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Sep 2015 19:48:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXY5TXHWYJRB4NGSGYAKGQEZ35MIHQ@isocpp.org Thu Sep 24 21:48:09 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZfCUt-0002n5-PO for gclcip-std-proposals@m.gmane.org; Thu, 24 Sep 2015 21:48:03 +0200 Original-Received: by laff1 with SMTP id f1sf27661268laf.2 for ; Thu, 24 Sep 2015 12:48:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type: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=RR3vdFFFvq6VRPUDp8SRsjq9vh6YFJZZ8IaTrmPkx7I=; b=e1efoMRuBlzASYwmsa+cQQAP9UjAwPwejlSVng4RZAw7EnHMoTHpVb2aTpPdB1bpV5 bgmMXYwVGZJS+lCSZBk2srORjVdc5IZ27iyJ21/9DeFm2HgizmnB/TUI/US6Coxmswf+ gTqdtdDKytxKotsJ4QhlFQKZq5o5tkDX5BzoYGJWVU/KpMG6jBrJtpLMjxfOO6MwPH9O REgnxii6ENTa38rnA7ZQJr9qDLl9LIfH23wBsWkbbtuRbtpDHdmowmV6ASYIYz4x2m9L 3E7OCNWR2r08DrEO9OUs7m5uXnh6ftUY1h6W+Zez+5Q8HRPTd+D0F2ECJomQU0ZnqNEB 6oUQ= X-Gm-Message-State: ALoCoQn9fTi2GijKJn8+ZccxogGM9YmAN5WGf+gzNPCvBjk9TAxo7q5Q3HDJWswPz9Onn88NPxSO X-Received: by 10.180.208.108 with SMTP id md12mr101417wic.1.1443124083042; Thu, 24 Sep 2015 12:48:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.5.164 with SMTP id t4ls124515lat.84.gmail; Thu, 24 Sep 2015 12:48:01 -0700 (PDT) X-Received: by 10.112.16.199 with SMTP id i7mr413062lbd.105.1443124081134; Thu, 24 Sep 2015 12:48:01 -0700 (PDT) Original-Received: from mail-la0-x231.google.com (mail-la0-x231.google.com. [2a00:1450:4010:c03::231]) by mx.google.com with ESMTPS id xv7si7301105lab.74.2015.09.24.12.48.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2015 12:48:01 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c03::231 as permitted sender) client-ip=2a00:1450:4010:c03::231; Original-Received: by lacdq2 with SMTP id dq2so20620573lac.1 for ; Thu, 24 Sep 2015 12:48:01 -0700 (PDT) X-Received: by 10.112.130.70 with SMTP id oc6mr458660lbb.32.1443124080561; Thu, 24 Sep 2015 12:48:00 -0700 (PDT) Original-Received: from [192.168.1.2] (broadband-90-154-68-200.nationalcablenetworks.ru. [90.154.68.200]) by smtp.googlemail.com with ESMTPSA id x1sm1209125lbb.32.2015.09.24.12.47.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2015 12:47:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <05602720-a61c-4e39-8898-3f886c869efa@isocpp.org> X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c03::231 as permitted sender) smtp.mailfrom=andrey.semashev@gmail.com; dkim=pass header.i=@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-Spam-Checked-In-Group: std-proposals@isocpp.org 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:20784 Archived-At: On 24.09.2015 21:21, Matthew Fioravante wrote: > > On Thursday, September 24, 2015 at 12:54:55 PM UTC-4, Andrey Semashev wrote: > > On Thu, Sep 24, 2015 at 7:35 PM, Matthew Fioravante > <_fmatth...@gmail.com_ > wrote: > > For all resources, we have owners who manage the lifetime of the > resource > > and viewers who view the resource. To be correct, all of the > viewers have to > > stop using the pointer before the last owner goes out of scope > and destroys > > the resource. > > If anything, this sounds fragile and dangerous. > > This was my concern as well and what I anticipate to be the biggest > argument against this idiom. However I'm not yet entirely convinced that > its any less dangerous to the situation where you have a > unique_ptr owned by A and viewed by B as a T*. Its up to the programmer > to ensure that B's lifetime is within A's lifetime. > If someone can identify a situation where optional_ptr is much more > dangerous than unique_ptr/T* that would be really helpful. unique_ptr/T* and optional_ptr are significantly different. You can use unique_ptr and raw pointers to the same object because you know who owns the object and is responsible for its deletion - the unique_ptr. With optional_ptr there is no distinction (on the interface level) and you are much more likely to destroy the owning optional_ptr leaving other optional_ptrs dangling. > But, in case you can easily guarantee that the owner outlives the > viewers, did you consider using unique_ptr with a custom deleter? > > I'm not sure how a custom deleter would help. If the deleter does > nothing, then you just have T*, if the deleter conditionally deletes the > object based on a boolean state, you have my optional_ptr. A reusable > common pattern should have a name, not be a backwards hack on a > unique_ptr deleter. Using unique_ptr with a no-op deleter (a.k.a. null_deleter) is not much different from using a raw pointer. I'm assuming you want optional_ptr type to be independent from whether it actually deletes the object or not. So yes, I was suggesting something like this: struct optional_deleter { optional_deleter() noexcept : m_f(false) {} explicit optional_deleter(bool f) noexcept : m_f(f) {} optional_deleter(optional_deleter&& that) noexcept : m_f(that.m_f) { that.m_f = false; } optional_deleter& operator= (optional_deleter&& that) noexcept { m_f = that.m_f; that.m_f = false; return *this; } template< typename T > void operator() (T* p) const noexcept { if (m_f) delete p; } private: bool m_f; }; template< typename T > using optional_ptr = unique_ptr< T, optional_deleter >; -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. .