[LLVMdev] New type of smart pointer for LLVM

[David Blaikie]

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>