<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 3:53 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 3:36 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <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">
<div text="#000000" bgcolor="#FFFFFF">
<div>Ping!<span><br>
</span><br>
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. <br>
The main difference from unique_ptr is an ability to access the
wrapped pointer after the ownership is transferred.<br>
To make the ownership clearer the wrapper is designed for
local-scope usage only.<br></div></div></blockquote><div><br></div></span><div>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).<br><br>I'd love to hear some more opinions, but maybe we're not going to get them... </div></blockquote></div><br></span>I strongly agree that the example here isn't compelling.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think it is a very fundamental design problem when there is a need for a pointer value after it has been deallocated...</div></div></blockquote><div><br></div><div>The use case here wasn't so much needing the pointer value after its been deallocated, but after ownership has been passed.<br><br>Essentially:<br><br> auto p = make_unique<T>(...);<br> addThing(std::move(p));<br> /* do more things with *p here... */<br><br>so you end up writing code like this:<br><br> auto pOwner = make_unique...<br> auto p = pOwner.get();<br> addThing(std::move(pOwner)<br> /* do things with *p here... */<br><br>Or you have the opposite:<br><br> std::unique_ptr<T> owner;<br> T *t;<br> if (x)<br> t = &defaultT;<br> else {</div><div> owner = make_unique...<br> t = owner.get();<br> }<br> /* stuff with t here... */<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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.<br></div></div></blockquote><div><br></div><div>Yep - this is the big open question for me & the dialog I really want to have about this (& why I've put off writing a maybe owning smart pointer so far). As I transform things to unique_ptr I tend to punt on any of the 'hard' ones, and this is one of them - so the ownership semantics non-unique_ptr-ified these days are becoming more and more these leftover cases.<br><br>The clearest example of such an API is something like Module... Duncan linked to a thread on that issue.<br><br>But I see a lot of it in Clang, simply grepping for "Owns" comesup with the following boolean members:<br><br>CodeGenAction::OwnsVMContext<br>ASTReader::OwnsDeserializationListener<br>Diagnostic::OwnsDiagClient<br>Preprocessor::OwnsHeaderSearch<br>TokenLexer::OwnsTokens<br>Action::OwnsInputs (this ones trickier - it's a boolean that indicates whether all the elements of a vector<T*> are owned or unowned)<br>ASTUnit::OwnsRemappedFileBuffers<br>VerifyDiagnosticConsumer::OwnsPrimaryClient<br>TextDiagnosticPrinter::OwnsOutputStream<br>FixItRewriter::OwnsClient<br>Tooling::OwnsAction<br><br>Some in LLVM:<br><br>circular_raw_ostream::OwnsStream<br>Arg::OwnsValues (another tricky one with a bool flag and a vector of raw pointers, if I recall correctly)<br><br><br>And a couple that I changed {T*, bool} to {T*, unique_ptr<T>}:<br><br>LogDiagnosticPrinter::StreamOwner<br>ASTUnit::ComputedPreamble::Owner<br><br></div></div><br></div></div>