220 21034 <6f71e4ef-02de-46a6-9387-7bcaf527a6bd@isocpp.org> article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: optional_ptr - A smart pointer which optionally owns the resource Date: Wed, 30 Sep 2015 07:50:12 -0700 (PDT) Lines: 228 Approved: news@gmane.org Message-ID: <6f71e4ef-02de-46a6-9387-7bcaf527a6bd@isocpp.org> 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/mixed; boundary="----=_Part_198_2008737894.1443624612366" X-Trace: ger.gmane.org 1443624617 25709 80.91.229.3 (30 Sep 2015 14:50:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 14:50:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBJPNV6YAKGQEVD44O3Y@isocpp.org Wed Sep 30 16:50:17 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZhIi0-0005AL-9H for gclcip-std-proposals@m.gmane.org; Wed, 30 Sep 2015 16:50:16 +0200 Original-Received: by pdbnu13 with SMTP id nu13sf69772754pdb.3 for ; Wed, 30 Sep 2015 07:50:14 -0700 (PDT) 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:message-id:in-reply-to:references :subject:mime-version:content-type: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=4TnVUJULVilnPGkMWC/YFoRn3cthOp59WNnY3Uw9dYQ=; b=EmMyxxneIW4OM0xdsPiO310eFivBvU1zqsO0bc7Smw5u3eUjNvWc4OHSlNhx5pNjE/ 0BaK/whDkQ0uAgqPAWa68+AGXXVk7NTCYiw8pX2UxTdauQraQmu1poKrpspHB7XWbKBf 8M3AE4cMyaF9oBTbbhc7E4F2nbHEGaX0XzLrGtabstn/DMHY09CiPMFBGH+lLMRmLpz7 pw24Xfng/bLWAJIqYnyfAPftzLAuVvXA4HWuWJy+SNvgb9+VubbTv6TIjd7jOuLduIeA /JCfnYJ8mj8w4k/ajuuBwpHBDxqsnaO21v63SXpwkRHGbDZawD7LgFrFVkHrEhEuqboa hgdg== X-Gm-Message-State: ALoCoQmxJwpBLzLEUzzP3Cv7z+LDZlwwelqrg8pEtcJ2RUVyuXMmr4CWFTccASSMZgpzMbkn00j2 X-Received: by 10.66.122.201 with SMTP id lu9mr3349275pab.8.1443624614219; Wed, 30 Sep 2015 07:50:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.137.104 with SMTP id qh8ls291540igb.7.gmail; Wed, 30 Sep 2015 07:50:13 -0700 (PDT) X-Received: by 10.50.114.36 with SMTP id jd4mr129364igb.6.1443624613131; Wed, 30 Sep 2015 07:50:13 -0700 (PDT) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.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:21034 Archived-At: ------=_Part_198_2008737894.1443624612366 Content-Type: multipart/alternative; boundary="----=_Part_199_1048050989.1443624612366" ------=_Part_199_1048050989.1443624612366 Content-Type: text/plain; charset=UTF-8 How about generalizing this idea to a erased_ptr which can be constructed from a unique_ptr&&, a shared_ptr, a weak_ptr or a plain ptr + bool. Internally this could be mainly a variant over the different pointer types, but with an operator-> which works as for any smart pointer. The pointer + owned == true constructor could maybe be equivalent to sending in a unique_ptr&& More thinking is definitely needed but intuitively it seemed to increase the usefulness to include also shared ownership in the mix. Den onsdag 30 september 2015 kl. 00:57:09 UTC+2 skrev Christopher Horvath: > > 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@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/. ------=_Part_199_1048050989.1443624612366 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about generalizing this idea to a erased_ptr<T> = which can be constructed from a unique_ptr&&, a shared_ptr, a weak_= ptr or a plain ptr + bool.

Internally this could be main= ly a variant over the different pointer types, but with an operator-> wh= ich works as for any smart pointer. The pointer + owned =3D=3D true constru= ctor could maybe be equivalent to sending in a unique_ptr&&

More thinking is definitely needed but intuitively it see= med to increase the usefulness to include also shared ownership in the mix.= =C2=A0


Den onsdag 30 september 2015 kl. 00:57:09 UTC+2 sk= rev Christopher Horvath:
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 vert= ex buffers.=C2=A0 Right now, in different implementations I have one soluti= on where everything is managed in one central place, which avoids having to= use shared_ptr by making everything's reference essentially a weak_ptr= ..=C2=A0 However, this is a brittle design and requires frequent changes to = multiple code locations.=C2=A0 A much better solution would be to have this= optional_ptr (or whatever it ends up being called, I agree that optional_p= tr 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_positions= ;
=C2=A0 = =C2=A0 std::shared_ptr<VertexBuffer> m_shared_positions;
=

<= font face=3D"monospace, monospace" size=3D"1">public:
=C2=A0 =C2=A0 // This assumes th= e invariant that one of the two pointers is non-null, enforced elsewhere
=C2=A0 =C2=A0= VertexBuffer& getVertexBuffer() { return m_unique_positions ? *m_uniqu= e_positions : *m_shared_positions; }
};

C

On Tue, Sep 29, 2015 at 3= :43 PM, Ross Smith <ross....@otoy.com> wrote:=
On 2015-09-30 07:38, Bengt Gustafs= son 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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/i= socpp.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>.
------=_Part_199_1048050989.1443624612366-- ------=_Part_198_2008737894.1443624612366-- .