<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 28, 2018, at 3:21 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><div class=""><br class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div><br class=""></div><div>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. </div><div><br class=""></div><div>BTW. my workaround that I mentioned functions by bridging the objc pointer to CFType and storing the CFTypeRef in the weak_ptr. </div><div><br class=""></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br class=""></blockquote></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="" style="margin: 0px; font-stretch: normal; line-height: normal; background-color: rgb(255, 255, 255);"><span class="">template<class _Tp></span><br class=""><span class="">class _LIBCPP_TEMPLATE_VIS weak_ptr</span><br class=""><span class="">{</span><br class=""><span class="">public:</span><br class=""><span class=""> typedef _Tp element_type;</span><br class=""><span class="">private:</span><br class=""><br class=""><br class=""><br class=""><font color="#251fff" class=""><span class="">#if </span>defined(__clang__) && <span class="">defined(__OBJC__) && __has_feature(objc_arc)</span></font></div><div class="" style="margin: 0px; font-stretch: normal; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);"><font color="#251fff" class=""><span class="" style="font-family: Helvetica; font-size: 12px;"> element_type __unsafe_unretained * __ptr_;</span><br class="" style="font-family: Helvetica; font-size: 12px;"><span class="" style="font-family: Helvetica; font-size: 12px;">#else</span></font><br class="" style="font-family: Helvetica; font-size: 12px;"><span class="" style="font-family: Helvetica; font-size: 12px;"> element_type* __ptr_;</span><br class="" style="font-family: Helvetica; font-size: 12px;"><span class="" style="font-family: Helvetica; font-size: 12px;"><font color="#271fff" class="">#endif</font></span><br class="" style="font-family: Helvetica; font-size: 12px;"><br class="" style="font-family: Helvetica; font-size: 12px;"><span class="" style="font-family: Helvetica; font-size: 12px;"> __shared_weak_count* __cntrl_;</span></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-James</div></body></html>