Nathan James via llvm-dev
2021-Jan-11 13:40 UTC
[llvm-dev] Add make_unqiue like function for IntrusiveRefCntPtr
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
David Blaikie via llvm-dev
2021-Jan-11 19:27 UTC
[llvm-dev] Add make_unqiue like function for IntrusiveRefCntPtr
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>