[LLVMdev] New type of smart pointer for LLVM

Anton Yartsev anton.yartsev at gmail.com
Thu Oct 2 02:43:33 PDT 2014

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141002/c6a9d70e/attachment.html>

More information about the llvm-dev mailing list