[PATCH] unique_ptrify llvm::getLazyBitcodeModule's MemoryBuffer parameter

[David Blaikie]

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