[PATCH] unique_ptr with ability to get a raw pointer after release.

[David Blaikie]

I'm really not sure this is the right approach... it's a bit creepy having
a std::unique_ptr own-yet-not-own like that. It also doesn't compose with
other deleters, which is a little unfortunate.

I'm wondering if this might be better approached by solving the more
general problem of "conditional ownership" which has turned up in several
places in LLVM and Clang. (ofter a T* and a boolean as members, the boolean
indicating whether the T* is owning or non-owning)

But to help demonstrate the use of this API - could you include the example
usage in this patch? (you mention a couple of code reviews where this came
up & I can't quite swap all the context back in from there to remember
exactly how this applies)

On Mon, Sep 22, 2014 at 11:12 AM, Антон Ярцев <anton.yartsev at gmail.com>
wrote:

> Hi dblaikie,
>
> The work is inspired by r215176 and comment to r217791.
> unique_ptr_deferred_release is intended for use in cases when conditional
> releases are mixed with raw pointer access, e.g:
>
>     unique_ptr_deferred_release<Type> P(new P);
>     if (cond) {
>       P.deferred_release();
>     }
>     assert(P.get()); // 'true' regardless of whether deferred_release()
> was called or not.
>     NonOwningFunction(P.get());
>
> Please review!
>
> http://reviews.llvm.org/D5443
>
> Files:
>   include/llvm/ADT/STLExtras.h
>   unittests/ADT/CMakeLists.txt
>   unittests/ADT/UniquePtrDeferredRelease.cpp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140922/444c9b87/attachment.html>