[LLVMdev] New type of smart pointer for LLVM

Chandler Carruth chandlerc at google.com
Wed Oct 1 15:53:58 PDT 2014

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).
> 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...

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/20141001/307211fb/attachment.html>

More information about the llvm-dev mailing list