[LLVMdev] New type of smart pointer for LLVM
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:
> 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...
More information about the llvm-dev