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

[Lang Hames]

Where unique_ptr fits the memory ownership model I'm all for using it. The
syntactic overhead is a small price to pay for self-documentation and
compile-time guarantees.

What are the objections?

Cheers,
Lang.



On Thu, Jul 17, 2014 at 4:21 PM, David Blaikie <dblaikie at gmail.com> wrote:

> There seems to be some uncertainty about the use of smart pointers
> (previously OwningPtr, now std::unique_ptr and std::shared_ptr
> predominantly) in the LLVM project as a whole, so here's a thread to
> discuss/clarify/etc the project preferences/direction with regard to
> smart pointer usage.
>
> For some context, see discussions in LLVM r212403 and Clang r213307.
>
> The basic question here seems to be whether smart pointer ownership is
> a direction we want to take the LLVM project in general.
>
> I've seen others contribute and have myself contributed many patches
> moving towards smart pointer ownership (both in the pre-C++11 days of
> OwningPtr, and much moreso in the post-C++11 world with
> std::unique_ptr and std::shared_ptr being usable inside containers, as
> return values, etc, allowing many more opportunities).
>
> std::unique_ptr's been used in LLD as far back as r153620.
> std::unique_ptr appeared in LLVM shortly after the C++11 switch with
> Ahmed's work to migrate the project from OwningPtr to std::unique_ptr
> (starting with r202609 and ending with r211259). Originally OwningPtr
> was added in r45261.
> Something in the order of 60 changes across clang and LLVM mention
> unique_ptr in their subject and migrate various APIs to use unique_ptr
> for ownership. Many of which remove uses of explicit delete or helpers
> like DeleteContainerPointers (and removing explicit dtors in many of
> those cases).
>
> Are people OK with/prefer the use of owning smart pointers in APIs?
> Are there places where you've found them to be too noisy/burdensome
> and would rather use raw pointers or some other abstraction? Would you
> prefer pre-commit review of such changes to adequately consider
> alternatives (such as?)?
>
> Thanks,
> - David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140717/40434c8f/attachment.html>