[LLVMdev] [cfe-dev] New type of smart pointer for LLVM

[Argyrios Kyrtzidis]

> On Nov 14, 2014, at 11:26 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Thu, Nov 13, 2014 at 2:20 PM, Argyrios Kyrtzidis <akyrtzi at gmail.com <mailto:akyrtzi at gmail.com>> wrote:
> 
>> On Nov 13, 2014, at 11:25 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> I'd generally prefer conditional ownership over shared ownership if possible - it's a narrower contract & I can still think about where the single owner is.
> 
> I’m not so sure. With unique_ptr and shared_ptr you know exactly what is the ownership, without needing to know where it came from, it is very clear.
> 
> Except that won't be true here - in at least some of these cases of conditional ownership, at the point where we enter into this arrangement we may not have ownership of the thing at all (it may've been passed down through several levels of non-owning, then we're calling into an API that has conditional ownership - or it may be a concrete object (stack or global) that cannot be shared) - if we used shared_ptr we could lie about it by creating a shared_ptr with a null deleter, which in some ways restricts the weirdness to where it's happening, but could be more confusing to developers rather than less (hey, I had this shared_ptr and somehow the object was destroyed - how could that ever happen? At least if it's conditional ownership they'll have a chance to realize that someone else is failing to live up to their side of the bargain)

I agree that lying with shared_ptr is bad; I’m advocating that we refactor the API and callers chain to use a real shared_ptr unless there is a strong reason not to.
If there is some rare ugly part that this is not possible we could debate it specifically and we may just live with the ugliness, but I’d prefer that we don’t make such unclear owning semantics easier to propagate.

>  
> With conditional ownership I will have to hunt around in the codebase and find the trail between different code paths for where the pointer came from, so that I know who owns it and in what conditions.
> 

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