[llvm-dev] Add make_unqiue like function for IntrusiveRefCntPtr

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 11 11:27:46 PST 2021

Yep, sounds good to me!

On Mon, Jan 11, 2021 at 5:40 AM Nathan James via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
> How would people feel about including a factory function for creating
> IntrusiveRefCntPtr objects, akin to how std::make_unique and its
> variants work. For the most part this change would just be code sugar,
> however it will clean up definitions and remove the need to duplicate
> the type name. I can also see this as a stepping stone to gradually
> making the constructor `IntrusiveRefCntPtr(T*)` explicit, preventing
> some accidental conversions which can easily result in undefined
> behaviour if say the object lives on the stack or is already owned by
> another object.
> Take this which is an example seen often throught the code base,
> appologies in advance if email formatting is kaput.
> >IntrusiveRefCntPtr<OverlayFileSystem> OFS(
> >    new OverlayFileSystem(getRealFileSystem()));
> >IntrusiveRefCntPtr<InMemoryFileSystem> IMFS(new InMemoryFileSystem);
> >OFS->pushOverlay(IMFS);
> Using A factory these could be cleaned up a lot.
> >auto OFS = makeIntrusive<OverlayFileSystem>(getRealFileSystem());
> >auto IMFS = makeIntrusive<InMemoryFileSystem>();
> >OFS->pushOverlay(IMFS);
> This wouldn't be in violation of the rules on using `auto` for
> declarations as the type is spelt in the initialisation.
> Thanks for reading,
> Nathan James
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210111/96c05224/attachment.html>

More information about the llvm-dev mailing list