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

[James Gregurich via cfe-dev]

> On Mar 29, 2018, at 11:50 AM, John McCall <rjmccall at apple.com> wrote:
> 
> 
> 
>> On Mar 29, 2018, at 11:08 AM, James Gregurich <bayoubengalml at mac.com <mailto: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,


not really.   it works like this in practice..


auto tmpSPtr = make_sptr([[cTest alloc] init]);

auto tmpWPtr = make_weak_ptr(tmpT4SPtr);
   
auto tmp2SPtr = tmpT4WPtr.lock();


the deallocator and other boiler plate is hidden behind abstractions that make it convenient to code.

You don't use shared_ptr for everything. you use it for things like window controllers...big classes that are rarely created and destroyed but for which there is great value in being able to do weak references for asynchronous callbacks to avoid retain cycles.

for things like temporary values or simple property storage you use unique_ptr in the same manner. There is no unnecessary overhead for the unique_ptr version...


@interface cTest : NSObject
{
	ns_guard<NSString> mMyNameSPtr;
}

@end

-(instancetype) init
{
	self = [super init];
	
	mMyNameSPtr = make_guard([[NSMutableString alloc] init]);
	
	return self;
}


At that point my memory management is  automatic and deallocators are trivial or unnecessary.  There is tremendous utility in this mechanism.  once in a while, I run instruments with the leak detector to check my work. is very, very rare that I find that I have written code that leak objc pointers.   


> compared to just using your own smart pointer class.

ok.    How would I write my own shared/weak smart pointer combo that only uses the objc retain counting without ARC? As I said repeatedly, the only way I can see to do it is have an independent counter...at that point, I'd be re-creating std::shared_ptr and std::weak_ptr anyway. 


btw. doing that would be pointless for unique_ptr as it already does the job with no unnecessary overhead once a custom deallocator is supplied. 


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


well...if I can't get it done, then I can't get it done. I'll just cope with a toolchain that doesn't work correctly when ARC is enabled.  I already have workarounds that function well.   it would just be nice if Apple's tool chain worked correctly out of the box with standard c++ practices so that we don't have to resort to extra games to work around the fallings-short of the design of ARC. It all works correctly if ARC is off.






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