[cfe-dev] objc++ enhancements for new c++ features

[John McCall via cfe-dev]

> On Mar 29, 2018, at 11:08 AM, James Gregurich <bayoubengalml at mac.com> wrote:
> 
> 
> 
>> On Mar 28, 2018, at 4:36 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>> 
>> 
>>> On Mar 28, 2018, at 4:48 PM, James Gregurich <bayoubengalml at mac.com <mailto:bayoubengalml at mac.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Mar 28, 2018, at 3:21 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>>> 
>>>> I absolutely understand the benefits of having smart pointer types that automatically manage your retains and releases.  I'm not arguing that you shoudn't use smart pointers.  I don't know why you specifically want to call your smart pointers std::shared_ptr and std::weak_ptr, though, because you are just creating problems for yourself.
>>> 
>>> 
>>> Why should one re-invent the wheel? the std classes work great in the non-arc mode.
>> 
>> I don't understand how.  In non-ARC mode, std::shared_ptr will not retain the value it holds or release it when the shared_ptr is destroyed.  It will *compile*, of course, and probably run fine in many cases because of the autorelease pool.
> 
> 
> you supply a custom deallocator that calls release when appropriate.

And then you ensure that you always construct one with a retained value?

This is a really-high overhead solution, both cognitively and in runtime performance, compared to just using your own smart pointer class.

If you wanted to ask libc++ for a standard smart-pointer class for Objective-C pointer types when Objective-C is enabled, well, I don't know if they'd take it, but it seems more likely that they would take it than that they'd accept a custom partial specialization of std::shared_ptr and std::weak_ptr for Objective-C pointer types.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180329/1d0ce053/attachment.html>