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

[James Gregurich via cfe-dev]

> On Mar 28, 2018, at 4:36 PM, John McCall <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.

>> 
>> 
>> template<class _Tp>
>> class _LIBCPP_TEMPLATE_VIS weak_ptr
>> {
>> public:
>>     typedef _Tp element_type;
>> private:
>> 
>> 
>> 
>> #if defined(__clang__) && defined(__OBJC__) && __has_feature(objc_arc)
>>     element_type __unsafe_unretained * __ptr_;
>> #else
>>     element_type*        __ptr_;
>> #endif
>> 
>>     __shared_weak_count* __cntrl_;
> 
> This would break std::weak_ptr for all non-ObjC element types.
> 

doh!  you're right. slight hole in my thinking. Its what I get for speaking off the top of my head.  Let me actually go prototype the changes in a real project so I don't look stupid again.  :) 






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