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

[James Gregurich via cfe-dev]

> On Mar 28, 2018, at 3:21 PM, John McCall <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.  Once the bug in ARC was fixed, shared_ptr worked exactly as it should with respect to ARC. weak_ptr would also work correctly too with a minor adjustment that should not affect anyone not using objc++ and ARC. Secondly, I'm not aware of any way that weak referencing smart pointer could be implemented only using retain, release and autorelease calls....which is useful in sharing resources across threads and dispatch tasks and allowing for asynchronous callbacks. You'd basically have to clone what shared_ptr and weak_ptr already do. 

BTW. my workaround that I mentioned functions by bridging the objc pointer to CFType and storing the CFTypeRef in the weak_ptr.  



> This would be adding some pretty unusual non-orthogonality in an attempt to make std::shared_ptr and std::weak_ptr do things they're not meant to do, which is transparently interoperate with a completely foreign shared-reference system.


Please pardon my ignorance...I''m not a compiler/standard-lib developer....but why is the following proposed change (in blue assuming that gets through to email clients) considered "non-orthogonal" or "unusual"?  Its a very straightforward change that wouldn't affect anyone but people using objc++ with ARC and weak_ptr. Based on my experience in implementing a rather large, complex system based on the mechanism, it would be the only change necessary.



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



I the end, the hook upon which I hang my hat is the argument that if a non-arc system is built on shared_ptr/weak_ptr, it should still work as expected once ARC is switched on...assuming it conforms to the rules laid out in the arc docs. 


-James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180328/07c55223/attachment.html>