220 21015 article Path: news.gmane.org!not-for-mail From: Christopher Horvath Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: optional_ptr - A smart pointer which optionally owns the resource Date: Tue, 29 Sep 2015 15:57:06 -0700 Lines: 184 Approved: news@gmane.org Message-ID: References: <7502c195-e5b9-4f04-8997-666933cef239@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f8e26ac38a30520eabb92 X-Trace: ger.gmane.org 1443567430 13697 80.91.229.3 (29 Sep 2015 22:57:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 22:57:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2YFPWU5AOBBQ5OVSYAKGQEBZPOP6Y@isocpp.org Wed Sep 30 00:57:10 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zh3pd-0006Y9-5j for gclcip-std-proposals@m.gmane.org; Wed, 30 Sep 2015 00:57:09 +0200 Original-Received: by vkgd64 with SMTP id d64sf28123790vkg.2 for ; Tue, 29 Sep 2015 15:57:08 -0700 (PDT) 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:date :message-id:subject:from: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=jlzxn7BH8PUHo8RQgTi/yIUpSD/dqtEyt9MAY/tVKSI=; b=Rx59J2H+m85l8WIfbP6VvZ7kDUPPFAP+dUyXzbhpL1T862Od5x+vDbP7sT08NOeHT8 TwsRsNLWv9Ur7FD30IQLq1Ev2gnzAA8lS2Ua6Vw5nU/91WNz2oUrg96C1gQgZGqaMuOn ysfLwzg60RNJw5w9mp8Qmr4uv8u/LMrwIYNRsbBG2v290WXzNUG2fwmNZ/xtNGnKLKeU glu3+2cw1KSS4IE3yqquNna3hg8V6hgrTzkcQgirdR5S9oI0GJeknZ0nXTckwi8hg+6B oaDZR4spqs635zlxF2MbgFrQpo82513vE0tO2mBe15d0DodTLFByQ+XuZWukVOZR948Q 53Qw== X-Gm-Message-State: ALoCoQkmTCPwNqXKwb4L75wmfqhuI0LRUlMgTnCgZ6nsSS4T7ng58NGz20zbICZHA3tKn7AmLbOA X-Received: by 10.13.233.197 with SMTP id s188mr453931ywe.23.1443567428323; Tue, 29 Sep 2015 15:57:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.29.36 with SMTP id g4ls1256437igh.31.canary; Tue, 29 Sep 2015 15:57:07 -0700 (PDT) X-Received: by 10.107.128.145 with SMTP id k17mr1632831ioi.24.1443567427312; Tue, 29 Sep 2015 15:57:07 -0700 (PDT) Original-Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com. [2607:f8b0:4001:c06::22e]) by mx.google.com with ESMTPS id i19si18616662igt.102.2015.09.29.15.57.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 15:57:07 -0700 (PDT) Received-SPF: pass (google.com: domain of blackencino@gmail.com designates 2607:f8b0:4001:c06::22e as permitted sender) client-ip=2607:f8b0:4001:c06::22e; Original-Received: by iofb144 with SMTP id b144so28489986iof.1 for ; Tue, 29 Sep 2015 15:57:07 -0700 (PDT) X-Received: by 10.107.9.151 with SMTP id 23mr1606089ioj.170.1443567426613; Tue, 29 Sep 2015 15:57:06 -0700 (PDT) Original-Received: by 10.36.78.20 with HTTP; Tue, 29 Sep 2015 15:57:06 -0700 (PDT) In-Reply-To: X-Original-Sender: blackencino@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of blackencino@gmail.com designates 2607:f8b0:4001:c06::22e as permitted sender) smtp.mailfrom=blackencino@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:21015 Archived-At: --001a113f8e26ac38a30520eabb92 Content-Type: text/plain; charset=UTF-8 I also run into this pattern fairly frequently. An example is in an OpenGL renderer, where a user may want to share vertex buffers between multiple meshes, but the default case is for the meshes to have unique vertex buffers. Right now, in different implementations I have one solution where everything is managed in one central place, which avoids having to use shared_ptr by making everything's reference essentially a weak_ptr. However, this is a brittle design and requires frequent changes to multiple code locations. A much better solution would be to have this optional_ptr (or whatever it ends up being called, I agree that optional_ptr is a bad name), instead of what I have now: // This is a sketch, please don't over-criticize! class Mesh { private: std::unique_ptr m_unique_positions; std::shared_ptr m_shared_positions; public: // This assumes the invariant that one of the two pointers is non-null, enforced elsewhere VertexBuffer& getVertexBuffer() { return m_unique_positions ? *m_unique_positions : *m_shared_positions; } }; C On Tue, Sep 29, 2015 at 3:43 PM, Ross Smith wrote: > On 2015-09-30 07:38, Bengt Gustafsson wrote: > >> I see this pattern quite often. Usually you want to keep the option open >> to send a pointer to a by value member to conserve allocations. Often in >> framework code when you want to keep options open for framework users. >> >> > One place I frequently need an optionally-owning pointer is in simple > command line utilities, where the user can optionally supply a file name to > read from (or write to), with a filename of "-" traditionally meaning "read > from standard input" (or "write to standard output"). So a lot of programs > intended to be run from the command line start with code like this (error > checking skipped for simplicity): > > string filename = argv[1]; > shared_ptr in; > if (filename == "-") > in.reset(&cin, [] (void*) {}); > else > in = make_shared(filename); > string line; > getline(*in, line); > > Another situation where I used an optionally-owning pointer recently is in > an image manipulation class, where the image class object might own the > image buffer itself, or might be operating on an image owned by some other > entity. > > Ross Smith > > > > -- > > --- 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/. > -- --- 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/. --001a113f8e26ac38a30520eabb92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also run into this pattern fairly frequently. An example= is in an OpenGL renderer, where a user may want to share vertex buffers be= tween multiple meshes, but the default case is for the meshes to have uniqu= e vertex buffers.=C2=A0 Right now, in different implementations I have one = solution where everything is managed in one central place, which avoids hav= ing to use shared_ptr by making everything's reference essentially a we= ak_ptr.=C2=A0 However, this is a brittle design and requires frequent chang= es to multiple code locations.=C2=A0 A much better solution would be to hav= e this optional_ptr (or whatever it ends up being called, I agree that opti= onal_ptr is a bad name), instead of what I have now:

// This is a sketch, please don= 't over-criticize!
class Mesh {
private:
=C2=A0 =C2=A0 std::unique_ptr<VertexBuffer> m_unique_posi= tions;
=C2= =A0 =C2=A0 std::shared_ptr<VertexBuffer> m_shared_positions;

public:
= =C2=A0 =C2=A0 // This assume= s the invariant that one of the two pointers is non-null, enforced elsewher= e
=C2=A0 = =C2=A0 VertexBuffer& getVertexBuffer() { return m_unique_positions ? *m= _unique_positions : *m_shared_positions; }
};

C
<= div>

On Tue, Sep 29, 2015 at 3:43 PM, Ross Smith <ross.smith@otoy.com&= gt; wrote:
On 201= 5-09-30 07:38, Bengt Gustafsson wrote:
I see this pattern quite often. Usually you want to keep the option open to= send a pointer to a by value member to conserve allocations. Often in fram= ework code when you want to keep options open for framework users.


 One place I frequently need an optionally-owning pointer is in simple comma= nd line utilities, where the user can optionally supply a file name to read= from (or write to), with a filename of "-" traditionally meaning= "read from standard input" (or "write to standard output&qu= ot;). So a lot of programs intended to be run from the command line start w= ith code like this (error checking skipped for simplicity):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 string filename =3D argv[1];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 shared_ptr<istream> in;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (filename =3D=3D "-")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in.reset(&cin, [] (void*) {})= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in =3D make_shared<ifstream>= ;(filename);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 string line;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 getline(*in, line);

Another situation where I used an optionally-owning pointer recently is in = an image manipulation class, where the image class object might own the ima= ge buffer itself, or might be operating on an image owned by some other ent= ity.

Ross Smith



--

--- You received this message because you are subscribed to the Google Grou= ps "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.
Visit this group at http://groups.google.c= om/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a113f8e26ac38a30520eabb92-- .