Thanks for the feedback!> > On Wed, Oct 1, 2014 at 3:36 PM, David Blaikie <dblaikie at gmail.com > <mailto:dblaikie at gmail.com>> wrote: > > On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev > <anton.yartsev at gmail.com <mailto:anton.yartsev at gmail.com>> wrote: > > Ping! > > Suggested is a wrapper over a raw pointer that is intended for > freeing wrapped memory at the end of wrappers lifetime if > ownership of a raw pointer was not taken away during the > lifetime of the wrapper. > The main difference from unique_ptr is an ability to access > the wrapped pointer after the ownership is transferred. > To make the ownership clearer the wrapper is designed for > local-scope usage only. > > > I'm still concerned this isn't the right direction, and that we > instead want a more formal "maybe owning pointer". The specific > use case you've designed for here, in my experience, doesn't seem > to come up often enough to justify a custom ADT - but the more > general tool of sometimes-owning smart pointer seems common enough > (& problematic enough) to warrant a generic data structure (and > such a structure would also be appliable to the TGParser use case > where this came up). >David, could you, please, clarify the concept of the "maybe owning pointer"?> > I'd love to hear some more opinions, but maybe we're not going to > get them... > > > I strongly agree that the example here isn't compelling. > > I think it is a very fundamental design problem when there is a need > for a pointer value after it has been deallocated...Not deallocated but stored to the long-living storage. I agree, the problem is in design, the suggested wrapper is an intermediate solution, it was just designed to replace the existing ugly fixes.> I even question whether we need a "maybe owning" smart pointer, or > whether this is just an indication that the underlying data structure > is *wrong*. The idea of "maybe" and "owning" going to gether, in any > sense, seems flat out broken to me from a design perspective, and so > I'm not enthused about providing abstractions that make it easier to > build systems with unclear ownership semantics.-- Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141002/c6a9d70e/attachment.html>
Duncan P. N. Exon Smith
2014-Oct-02 16:18 UTC
[LLVMdev] New type of smart pointer for LLVM
> On Oct 2, 2014, at 2:43 AM, Anton Yartsev <anton.yartsev at gmail.com> wrote: > >> I'm still concerned this isn't the right direction, and that we instead want a more formal "maybe owning pointer". The specific use case you've designed for here, in my experience, doesn't seem to come up often enough to justify a custom ADT - but the more general tool of sometimes-owning smart pointer seems common enough (& problematic enough) to warrant a generic data structure (and such a structure would also be appliable to the TGParser use case where this came up). > David, could you, please, clarify the concept of the "maybe owning pointer"?I think the idea is something like the compromise I suggested [1] as an alternative to misusing `std::unique_ptr<>`. But it's even better to design away "maybe-owning pointers" entirely. [1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/230727.html
On Thu, Oct 2, 2014 at 2:43 AM, Anton Yartsev <anton.yartsev at gmail.com> wrote:> Thanks for the feedback! > > > On Wed, Oct 1, 2014 at 3:36 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <anton.yartsev at gmail.com> >> wrote: >> >>> Ping! >>> >>> Suggested is a wrapper over a raw pointer that is intended for freeing >>> wrapped memory at the end of wrappers lifetime if ownership of a raw >>> pointer was not taken away during the lifetime of the wrapper. >>> The main difference from unique_ptr is an ability to access the wrapped >>> pointer after the ownership is transferred. >>> To make the ownership clearer the wrapper is designed for local-scope >>> usage only. >>> >> >> I'm still concerned this isn't the right direction, and that we instead >> want a more formal "maybe owning pointer". The specific use case you've >> designed for here, in my experience, doesn't seem to come up often enough >> to justify a custom ADT - but the more general tool of sometimes-owning >> smart pointer seems common enough (& problematic enough) to warrant a >> generic data structure (and such a structure would also be appliable to the >> TGParser use case where this came up). >> > David, could you, please, clarify the concept of the "maybe owning > pointer"? >See my reply to Chandler with a list of classes that hold {T*, bool} members where the bool indicates whether the T* needs to be deleted or not. My original goal here was to provide an API to make those more robust (more precisely: to remove the need to call "release()" and allow us to stay in a clear(er) owning domain).> > > >> I'd love to hear some more opinions, but maybe we're not going to get >> them... >> > > I strongly agree that the example here isn't compelling. > > I think it is a very fundamental design problem when there is a need for > a pointer value after it has been deallocated... > > Not deallocated but stored to the long-living storage. I agree, the > problem is in design, the suggested wrapper is an intermediate solution, it > was just designed to replace the existing ugly fixes. > > I even question whether we need a "maybe owning" smart pointer, or > whether this is just an indication that the underlying data structure is > *wrong*. The idea of "maybe" and "owning" going to gether, in any sense, > seems flat out broken to me from a design perspective, and so I'm not > enthused about providing abstractions that make it easier to build systems > with unclear ownership semantics. > > > -- > Anton > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141002/a68094c7/attachment.html>
[+cfe-dev] This conversation has already been happening on llvm-dev so there's no good way for me to capture the entire existing discussion (so I'm jumping you in part-way) & the subject line could be more descriptive, but I wanted to add Clang developers since many of the interesting cases of conditional ownership I've seen were in Clang. I know some of you are also on llvm-dev but not active readers, so it might be worth using this as a jumping off point to go & find the full llvm-dev thread, read that and, when replying, add cfe-dev. If anyone not on llvm-dev wants some more context there's the email archive here ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/thread.html#77136 ) and/or I'm happy to provide more context/summary myself. On Thu, Oct 2, 2014 at 9:44 AM, David Blaikie <dblaikie at gmail.com> wrote:> > > On Thu, Oct 2, 2014 at 2:43 AM, Anton Yartsev <anton.yartsev at gmail.com> > wrote: > >> Thanks for the feedback! >> >> >> On Wed, Oct 1, 2014 at 3:36 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <anton.yartsev at gmail.com> >>> wrote: >>> >>>> Ping! >>>> >>>> Suggested is a wrapper over a raw pointer that is intended for freeing >>>> wrapped memory at the end of wrappers lifetime if ownership of a raw >>>> pointer was not taken away during the lifetime of the wrapper. >>>> The main difference from unique_ptr is an ability to access the wrapped >>>> pointer after the ownership is transferred. >>>> To make the ownership clearer the wrapper is designed for local-scope >>>> usage only. >>>> >>> >>> I'm still concerned this isn't the right direction, and that we >>> instead want a more formal "maybe owning pointer". The specific use case >>> you've designed for here, in my experience, doesn't seem to come up often >>> enough to justify a custom ADT - but the more general tool of >>> sometimes-owning smart pointer seems common enough (& problematic enough) >>> to warrant a generic data structure (and such a structure would also be >>> appliable to the TGParser use case where this came up). >>> >> David, could you, please, clarify the concept of the "maybe owning >> pointer"? >> > > See my reply to Chandler with a list of classes that hold {T*, bool} > members where the bool indicates whether the T* needs to be deleted or not. > My original goal here was to provide an API to make those more robust (more > precisely: to remove the need to call "release()" and allow us to stay in a > clear(er) owning domain). > > >> >> >> >>> I'd love to hear some more opinions, but maybe we're not going to get >>> them... >>> >> >> I strongly agree that the example here isn't compelling. >> >> I think it is a very fundamental design problem when there is a need >> for a pointer value after it has been deallocated... >> >> Not deallocated but stored to the long-living storage. I agree, the >> problem is in design, the suggested wrapper is an intermediate solution, it >> was just designed to replace the existing ugly fixes. >> >> I even question whether we need a "maybe owning" smart pointer, or >> whether this is just an indication that the underlying data structure is >> *wrong*. The idea of "maybe" and "owning" going to gether, in any sense, >> seems flat out broken to me from a design perspective, and so I'm not >> enthused about providing abstractions that make it easier to build systems >> with unclear ownership semantics. >> >> >> -- >> Anton >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141008/2398b0c0/attachment.html>