220 20779 article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: optional_ptr - A smart pointer which optionally owns the resource Date: Thu, 24 Sep 2015 11:59:58 -0700 (PDT) Lines: 175 Approved: news@gmane.org Message-ID: References: <7502c195-e5b9-4f04-8997-666933cef239@isocpp.org> <269e8a7b-410a-4bde-a826-93050cbfb655@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_959_1113074978.1443121198409" X-Trace: ger.gmane.org 1443121213 6807 80.91.229.3 (24 Sep 2015 19:00:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Sep 2015 19:00:13 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDELF54RTIGRBL4QSGYAKGQET22ZHWI@isocpp.org Thu Sep 24 21:00:01 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZfBkO-0005Vx-Qw for gclcip-std-proposals@m.gmane.org; Thu, 24 Sep 2015 21:00:00 +0200 Original-Received: by qkfj65 with SMTP id j65sf114947655qkf.2 for ; Thu, 24 Sep 2015 11:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=zw8VLq1EcSp9MKMiVogaU8TT5g5kGf7q/nnt+6Z+dH4=; b=PiE7dsb1BrNcLKNzgxPVO7qi99yFQ1PRG/5zeNbNM6CLjEBiju+XdZUf9+Ch0itKKw QgcWlhFtlqc6C5+tXWD0u+A5vHKMyUvu7zlOqWdUR24y+OCImCEwttmEkDmm3IUSbj8M Zpgz7ra28gFnJPGH1wFYMg2VUchnbN4ZCvap2gnrDmfZ6U6vFDfuqEs6/HERVMBMbvd6 P+pSjZgToLy9ZZNKciHAiHRnGJ54TfpXrm8UvKrRoeL7EbeR5WNctz/Ej71mJT9+Nbz2 Cpbx8qsbwkIU7U54KeAoe3sjGl/OYMvzelDustjfY4iw0sSZNDuPpvlxmGjikTHvUEut v/Ag== 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=zw8VLq1EcSp9MKMiVogaU8TT5g5kGf7q/nnt+6Z+dH4=; b=WhXxfKq5fGfBVURyfN+QEywr3lpCnwScPre1Sq7kx2hc8ksnD+dI6unBIov7dkGev+ 7yqy1fpACJT3t2Yc3FQfaU0uYtPyg4N1L/hWU7dXi1ND0L5u18KG5zD/CqjtnThZe3Mx soPXWFDm7r0a7u62rJUz2isaGFjVVKcr7jhjvm+BK1UWjX8ceiJGoN0fIv0DDfKrugaZ rnOF/NPz4b4pWP9+Tl0fBYEbScKpK9tjwSh3IWMFzDWQRQx26J5VCx8C42XsHOxrMrNd /xLKiTxBZsbLxCgfjqmbR4CvVq9n2VR+YW0TMOW9mWhe/+a7BTugFJG7eE3f/Xs5Z5PC eLww== X-Gm-Message-State: ALoCoQmUKe+GEdu6xCpZp/zYItFsDeCjh/GQ35GHNPL2QX2nreqYF6ED4kN3XpclzWvpm1I1o/NZ X-Received: by 10.13.234.9 with SMTP id t9mr1053655ywe.17.1443121199829; Thu, 24 Sep 2015 11:59:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.132.67 with SMTP id os3ls7274igb.26.gmail; Thu, 24 Sep 2015 11:59:59 -0700 (PDT) X-Received: by 10.50.77.39 with SMTP id p7mr383445igw.7.1443121199035; Thu, 24 Sep 2015 11:59:59 -0700 (PDT) In-Reply-To: <269e8a7b-410a-4bde-a826-93050cbfb655@isocpp.org> X-Original-Sender: fmatthew5876@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:20779 Archived-At: ------=_Part_959_1113074978.1443121198409 Content-Type: multipart/alternative; boundary="----=_Part_960_1674979995.1443121198409" ------=_Part_960_1674979995.1443121198409 Content-Type: text/plain; charset=UTF-8 Nicol, I can provide another general use case, again related to building pipelines. Lets imagine we have data streams. In my example, each data stream will an object represented by a letter. For example, we have can a stream A, and another stream B(A) which takes A, performs some transformations, and then produces new stream B. B accesses A by storing a pointer to A. A common case is one producer and many consumers. A B(A) C(A) D(A) In this case, A can be owned externally (via unique_ptr or directly on the stack/data member) and B, C, and D get a view to it. However we can also have this scenario. D(C(B(A))). Here, maybe I'm only interested in the output of D, not the intermediate C, B, and A streams. A, B, and C may even be completely hidden via a factory function that creates D. In this case, the most natural thing is to just let them tag along with D and let D own them. Since D is the only consumer, once D goes away C, B, and A can all be destroyed. I don't have to manage any external object to maintain the unique_ptr's that own A, B, and C. Of course this can all be solved by shared_ptr, but for reasons mentioned earlier that has a lot of drawbacks. In my mind shared_ptr is only really needed when you cannot build a heirarchical scoped architecture to manage the lifetime invariants for you. I try to avoid it unless absolutely necessary. Essentially using unique_ptr/T* means that you always have to have an external manager object to take ownership of the lifetimes. If you want to construct an producer and consumer in isolation you also need a third object to hold the unique_ptr object. With optional_ptr, the consumer can just take the producer if needed. On Thursday, September 24, 2015 at 2:46:51 PM UTC-4, Jeffrey Yasskin wrote: > > On Thu, Sep 24, 2015 at 11:32 AM, Matthew Fioravante < > *fmatth...@gmail.com* > wrote: > >> >> On Thursday, September 24, 2015 at 1:53:47 PM UTC-4, Jeffrey Yasskin >> wrote: >>> >>> We have an optional ownership pattern at Google, involving storing an >>> enum next to the pointer. It's fairly bad, but it gets the job done. >>> >> Hi Jeffrey, could you expand on some specific use cases? Why did you feel >> the need to invent optional ownership? Why were the built in unique and >> shared ownership patterns not adequate? >> > > Many uses are in wrappers around other data, for example, a gunzip view on > a string or a filtered view of a table, where the library fundamentally > only needs a view on the data, but in many cases the user doesn't want to > deal with stashing ownership of the data somewhere else. Uses are about > evenly split between ones that want the library to take ownership and ones > that don't. > That sounds pretty similar to my use case, another pipeline. -- --- 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_960_1674979995.1443121198409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nicol, I can provide another general use case, again = related to building pipelines.
=C2=A0
Lets imagine we h= ave data streams. In my example, each data stream will an object represente= d by a letter.
=C2=A0
For example, we have can a stream= A, and another stream B(A) which takes A, performs some transformations, a= nd then produces=C2=A0new stream B. B accesses A by=C2=A0storing a pointer = to A.
=C2=A0
A common case is one producer and many con= sumers.
=C2=A0
A
B(A)
C(A)
D(A)
=C2=A0
In this case, A can be owned externally (= via unique_ptr or directly on the stack/data member) and B, C, and D get a = view to it.
=C2=A0
However we can also have this scenar= io.
=C2=A0
D(C(B(A))).
=C2=A0
Here,= maybe I'm only interested in the output of D, not the intermediate C, = B, and A streams. A, B, and C may even be completely hidden via a factory f= unction that creates D. In this case, the most natural thing is to just let= them tag along with D and let D own them. Since D is the only consumer, on= ce D goes away C, B, and A can all be destroyed. I don't have to manage= any external object to maintain the unique_ptr's that own A, B, and C.=
=C2=A0
Of course this can all be solved by shared_ptr,= but for reasons mentioned earlier that has a lot of drawbacks. In my mind = shared_ptr is only really needed when you cannot build a heirarchical scope= d architecture to manage the lifetime invariants=C2=A0for you. I try to avo= id it unless absolutely necessary.
=C2=A0
Essentially u= sing unique_ptr/T* means that you always have to have an external manager o= bject to take ownership of the lifetimes. If you want to construct an produ= cer and consumer in isolation you also need a third object to hold the uniq= ue_ptr object. With optional_ptr, the consumer can just take the producer i= f needed.
=C2=A0
=C2=A0

On Thursday, Sept= ember 24, 2015 at 2:46:51 PM UTC-4, Jeffrey Yasskin wrote:
On Thu, Sep 24= , 2015 at 11:32 AM, Matthew Fioravante <fmatth...@gmail.com> wrote:

On Thursday, September 24, 201= 5 at 1:53:47 PM UTC-4, Jeffrey Yasskin wrote:
<= div dir=3D"ltr">We have an optional ownership pattern at Google, involving = storing an enum next to the pointer. It's fairly bad, but it gets the j= ob done.
Hi Jeffrey, could you ex= pand on some specific use cases? Why did you feel the need to invent option= al ownership? Why were the built in unique and shared ownership patterns no= t adequate?

Many uses are in wr= appers around other data, for example, a gunzip view on a string or a filte= red view of a table, where the library fundamentally only needs a view on t= he data, but in many cases the user doesn't want to deal with stashing = ownership of the data somewhere else. Uses are about evenly split between o= nes that want the library to take ownership and ones that don't.
<= /div>
=C2=A0
That sounds prett= y similar to my use case, another pipeline.
=C2=A0
=C2= =A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0

--

---
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_960_1674979995.1443121198409-- ------=_Part_959_1113074978.1443121198409-- .