<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 29, 2018, at 11:50 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2018, at 11:08 AM, James Gregurich <<a href="mailto:bayoubengalml@mac.com" class="">bayoubengalml@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 28, 2018, at 4:36 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 28, 2018, at 4:48 PM, James Gregurich <<a href="mailto:bayoubengalml@mac.com" class="">bayoubengalml@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><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 class="" 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;">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 class="" 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;"></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Why should one re-invent the wheel? the std classes work great in the non-arc mode.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">you supply a custom deallocator that calls release when appropriate.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">And then you ensure that you always construct one with a retained value?</div><div class=""><br class=""></div>This is a really-high overhead solution, both cognitively and in runtime performance, </div></div></blockquote><div><br class=""></div><div><br class=""></div><div>not really. it works like this in practice..</div><div><br class=""></div><div><br class=""></div><div><div style="margin: 0px; font-stretch: normal; font-size: 14px; line-height: normal; font-family: Menlo; color: rgb(52, 149, 175); background-color: rgb(255, 255, 255);" class=""><span style="color: #0433ff" class="">auto</span><span style="color: #000000" class=""> tmpSPtr = </span>make_sptr<span style="color: #000000" class="">([[</span>cTest<span style="color: #000000" class=""> </span>alloc<span style="color: #000000" class="">] </span>init<span style="color: #000000" class="">]);</span></div></div><div><span style="font-family: Menlo; font-size: 14px; background-color: rgb(255, 255, 255); color: rgb(4, 51, 255);" class=""><br class=""></span></div><div><span style="font-family: Menlo; font-size: 14px; background-color: rgb(255, 255, 255); color: rgb(4, 51, 255);" class="">auto</span><span style="font-family: Menlo; font-size: 14px; background-color: rgb(255, 255, 255);" class=""> tmpWPtr = </span><span style="font-family: Menlo; font-size: 14px; background-color: rgb(255, 255, 255); color: rgb(52, 149, 175);" class="">make_weak_ptr</span><span style="font-family: Menlo; font-size: 14px; background-color: rgb(255, 255, 255);" class="">(tmpT4SPtr);</span></div><div><p style="margin: 0px; font-stretch: normal; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255); min-height: 16px;" class=""> <br class="webkit-block-placeholder"></p><div style="margin: 0px; font-stretch: normal; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="color: #0433ff" class="">auto</span> tmp2SPtr = tmpT4WPtr.<span style="color: #3495af" class="">lock</span>();</div></div><div><br class=""></div><div><br class=""></div><div>the deallocator and other boiler plate is hidden behind abstractions that make it convenient to code.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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...</div><div><br class=""></div><div><br class=""></div><div>@interface cTest : NSObject</div><div>{</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>ns_guard<NSString> mMyNameSPtr;</div><div>}</div><div><br class=""></div><div>@end</div><div><br class=""></div><div>-(instancetype) init</div><div>{</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>self = [super init];</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>mMyNameSPtr = make_guard([[NSMutableString alloc] init]);</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return self;</div><div>}</div><div><br class=""></div><div><br class=""></div><div>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. </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div 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="">compared to just using your own smart pointer class.</div></div></blockquote><div><br class=""></div><div><div>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. </div><div><br class=""></div></div><div><br class=""></div><div>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. </div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div 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="">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.</div></blockquote><br class=""></div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div></body></html>