[LLVMdev] New type of smart pointer for LLVM

[David Blaikie]

On Thu, Sep 25, 2014 at 1:44 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 25 September 2014 06:16, David Blaikie <dblaikie at gmail.com> wrote:
> > I can go & dredge up some examples if we want to discuss the particular
> > merits & whether each of those cases would be better solved in some other
> > way, but it seemed pervasive enough in the current codebase that some
> > incremental improvement could be gained by replacing these cases with a
> more
> > specific tool for the job. We might still consider this tool to be "not
> > ideal".
>
> Having done that in another code base, I can see both merits and problems.
>
> Our smart pointer behaved more or less like it's described above
> (explicit acquire/release)


I'm not quite sure I follow you (or that you're following me). The goal
isn't about being explicit about acquire/release (indeed I wouldn't mind
more implicit acquisition from an always-owning pointer (unique_ptr) to a
sometimes-owning pointer (whatever we end up calling it), though release is
always going to be explicit I suspect).


> and we've seen around 20% performance
> improvement over shared_ptr due to savings on acquire/release
> semantics.


The existing use cases I'm interested in aren't using shared_ptr and
wouldn't be ideally migrated to it (in some cases the existing ownership
might be on the stack (so it can't be shared) or several layers up the call
stack through which raw pointers have been passed (eg: build something,
pass it through a few APIs, underlying thing 'wants' to take ownership, but
it will be constructed/destroyed before this API returns - so we hack
around it either by having a "OwnsThing" flag in the underlying thing, or
having a "takeThing" we hope we call before the underlying thing dies and
destroys the thing)).

We're dealing with types that have raw pointer + bool indicating ownership
members or worse, types which take ownership but we lie to about giving
them ownership (so some API takes a non-owning T* (or T&), passes it as
owning to some other thing, then is sure to take ownership back from that
thing and call 'release()" on the unique_ptr to ensure ownership was never
really taken).


> We had three derivative types of pointers
> (Shared/Owned/Linked) which would just differ on the default behaviour
> of construction / destruction, but all of them could still explicitly
> call getClear / getLink / etc.
>
> The downside was that almost every interaction with smart pointers had
> to be carefully planned and there was a lot of room for errors,
>

My hope is that having a single construct for conditional ownership will be
less confusing than the existing ad-hoc solutions in many places. It's
possible that the right answer is to remove the conditional ownership in
these APIs entirely, but I'm not sure that's possible/practical/desired (it
might be - which is why I've been hesitant to write this abstraction myself
just yet - sort of letting it stew in my head a bit to see what feels
right).


> especially from people that didn't know the context. In the end, the
> amount of work that had to be put to make it work was similar than
> when dealing with normal pointers,


I rather hope that's not the case - these conditionally owning raw pointers
are pretty subtle, easy to miss a delete and leak, easy to have an early
return and fail to take back and release ownership from something that
wasn't really owning in the first place, etc.


> but you had to learn yet another
> pointer semantics.
>
> The marginal gain was that pointer interactions were explicit, making
> it easier for someone *not* used to C++ pointer semantics to
> understand when reading code, not necessarily when writing it. The
> marginal lost was getting people that already knew the STL and Boost
> smart pointer semantics to get confused.
>

This is another pointer semantic - I'm not suggesting replacing unique_ptr
or shared_ptr - I want to use them as much as possible where they represent
the right semantic. I'm just dealing with a situation that doesn't map
directly to either of those: conditional ownership.


>
> Having done that, I still rather use normal pointers and have valgrind
> / sanitizers tell me when I screwed up.
>
> My tuppence.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140925/84124a3c/attachment.html>