[llvm-dev] Add make_unqiue like function for IntrusiveRefCntPtr

Fangrui Song via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 11 11:30:32 PST 2021


On 2021-01-11, David Blaikie via llvm-dev wrote:
>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.

Sounds good, but `RefCnt` probably should be part of the name.

>> 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
>>

>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



More information about the llvm-dev mailing list