[LLVMdev] New type of smart pointer for LLVM
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 unique_ptr 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<T>(...);
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<T> 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<T>}:
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