<div dir="ltr">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.<br><br>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)<br><br>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)<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 11:12 AM, Антон Ярцев <span dir="ltr"><<a href="mailto:anton.yartsev@gmail.com" target="_blank">anton.yartsev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi dblaikie,<br>
<br>
The work is inspired by r215176 and comment to r217791.<br>
unique_ptr_deferred_release is intended for use in cases when conditional releases are mixed with raw pointer access, e.g:<br>
<br>
    unique_ptr_deferred_release<Type> P(new P);<br>
    if (cond) {<br>
      P.deferred_release();<br>
    }<br>
    assert(P.get()); // 'true' regardless of whether deferred_release() was called or not.<br>
    NonOwningFunction(P.get());<br>
<br>
Please review!<br>
<br>
<a href="http://reviews.llvm.org/D5443" target="_blank">http://reviews.llvm.org/D5443</a><br>
<br>
Files:<br>
  include/llvm/ADT/STLExtras.h<br>
  unittests/ADT/CMakeLists.txt<br>
  unittests/ADT/UniquePtrDeferredRelease.cpp<br>
</blockquote></div><br></div></div>