[PATCH] unique_ptrify llvm::getLazyBitcodeModule's MemoryBuffer parameter
David Blaikie
dblaikie at gmail.com
Tue Aug 12 16:27:19 PDT 2014
On Tue, Aug 12, 2014 at 4:07 PM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
>
>> On 2014-Aug-12, at 15:50, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> Maybe that's what it'll come to - I really dislike optional ownership,
>> but if used judiciously it might be a tool we need in our toolkit.
>> This certainly isn't the only place where this API conundrum has come
>> up.
>>
>> - David
>
> I guess another option is to use `shared_ptr<MemoryBuffer>`. Then the
> caller decides whether to keep ownership.
>
> You can use a null deleter to handle unowned MemoryBuffers if necessary.
>
> template <class T> struct null_deleter {
> void operator()(T *) const {}
> };
> template <class T> std::shared_ptr<T> make_unowned_shared_ptr(T *P) {
> return std::shared_ptr<T>(P, null_deleter<T>());
> };
> ErrorOr<Module *> foo(MemoryBuffer &Buffer) {
> return getLazyBitcodeModule(make_unowned_shared_ptr(&Buffer));
> };
>
> Of course, this is just another way to "lie" about ownership.
It's sort of a nice lie... sort of.
Yeah... I was going to say I'd probably rather the maybe_unique_ptr
over this (narrower functionality, less memory/cognitive overhead
(when I see shared things I wonder who's sharing them and why), etc),
but as I think about it I'm not sure.
Again, just a bunch of options that don't feel great...
I wonder how bad the world would be if these things just never owned -
but that doesn't sound promising either.
Perhaps I'm just not having a very 'up' day ;)
- David
More information about the llvm-commits
mailing list