[cfe-dev] Use of Smart Pointers in LLVM Projects

[Lang Hames]

Hi Alp,

A clear place that smart pointers *shouldn't* be used are 'create'
> functions.
>
> There's already a strong convention in the thousands of 'create' functions
> across the codebase and they have the clear, well-defined behaviour of
> returning a new pointer.
>
> We all know what to expect from these functions, much like new/delete in
> C++ and malloc/free. They can be easily adopted by std::shared_ptr or
> std::unique_ptr as needed, so there's no benefit in enforcing smart pointer
> usage at creation.
>

I strongly disagree with this: If knowing that new'ed things must be
deleted was enough we would never have to worry about memory leaks. It's a
huge benefit to have the compiler catch our mistakes for us - it's one less
thing to worry about.


> Apart from the complexity and visual clutter, it's pretty annoying to have
> to decide whether to get(), release() or somehow else acquire the object
> you just created. The result of using smart pointers as returns isn't
> pretty -- you end up with awkward code like createFoo().get()->func() or
> other.reset(createFoo().release()).
>

I think if you were ever writing createFoo()->func() before you were
leaking memory. And actually you can now safely use the simpler syntax with
std::unique_ptr: createFoo()->func() will work fine, there's no need for
the .get().

Ditto other.reset(createFoo.release()). I think this would just be: other =
createFoo(), (or a = std::move(b);).

There may be occasions where you need to call .get() to pass a pointer as
an argument to a function that isn't taking ownership, but that doesn't
seem odious to me.

Cheers,
Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140717/7bc2545a/attachment.html>