[LLVMdev] New type of smart pointer for LLVM (original) (raw)

David Blaikie dblaikie at gmail.com
Thu Oct 2 09:39:39 PDT 2014

On Wed, Oct 1, 2014 at 3:53 PM, Chandler Carruth <chandlerc at google.com> wrote:

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 uniqueptr 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). 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...

The use case here wasn't so much needing the pointer value after its been deallocated, but after ownership has been passed.

Essentially:

auto p = make_unique(...); addThing(std::move(p)); /* do more things with *p here... */

so you end up writing code like this:

auto pOwner = make_unique... auto p = pOwner.get(); addThing(std::move(pOwner) /* do things with *p here... */

Or you have the opposite:

std::unique_ptr owner; T t; if (x) t = &defaultT; else { owner = make_unique... t = owner.get(); } / stuff with t here... */

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.

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.

The clearest example of such an API is something like Module... Duncan linked to a thread on that issue.

But I see a lot of it in Clang, simply grepping for "Owns" comesup with the following boolean members:

CodeGenAction::OwnsVMContext ASTReader::OwnsDeserializationListener Diagnostic::OwnsDiagClient Preprocessor::OwnsHeaderSearch TokenLexer::OwnsTokens Action::OwnsInputs (this ones trickier - it's a boolean that indicates whether all the elements of a vector<T*> are owned or unowned) ASTUnit::OwnsRemappedFileBuffers VerifyDiagnosticConsumer::OwnsPrimaryClient TextDiagnosticPrinter::OwnsOutputStream FixItRewriter::OwnsClient Tooling::OwnsAction

Some in LLVM:

circular_raw_ostream::OwnsStream Arg::OwnsValues (another tricky one with a bool flag and a vector of raw pointers, if I recall correctly)

And a couple that I changed {T*, bool} to {T*, unique_ptr}:

LogDiagnosticPrinter::StreamOwner ASTUnit::ComputedPreamble::Owner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141002/b300ad47/attachment.html>

More information about the llvm-dev mailing list