<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=""><div><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=""><br class=""></div><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="">I agree it would be great to get ARC-managed pointers working well in std::shared_ptr and std::weak_ptr. The usual subtlety with templates is that __strong doesn't show up in C++ mangling, so it's not straightforward to avoid ODR violations when ARC and MRR translation units are linked together. I think this is solvable, but I doubt it's trivial.</div></div></blockquote><div><br class=""></div><div><br class=""></div><div>I've come to the conclusion that mixing ARC and non-ARC c++ modules is not viable because of the ODR limitation. Its probably not worth the effort to make it viable. However, all-arc and all-non-arc are both perfectly viable. the use case is the situation where you have a big legacy codebase that will never be made ARC-compatible in its entirety but pieces of it need to work in an ARC process.</div><div><br class=""></div><div><br class=""></div><div>the memory header just needs to be changed like so...</div><div><br class=""></div><div>template<class _Tp><br class="">class _LIBCPP_TEMPLATE_VIS weak_ptr<br class="">{<br class="">public:<br class=""> typedef _Tp element_type;<br class="">private:<br class=""><br class=""><br class=""><br class="">#if defined(__OBJC__) && __has_feature(objc_arc)<br class=""> element_type __unsafe_unretained * __ptr_;<br class="">#else<br class=""> element_type* __ptr_;<br class="">#endif<br class=""><br class=""> __shared_weak_count* __cntrl_;<br class=""><br class=""></div><div><br class=""></div><div><blockquote type="cite" class="">I'm skeptical of inventing an ObjC++-specific terse lambda syntax. I'm tempted to let C++ evolve/improve lambda syntax first.</blockquote></div></div><br class=""><div class="">There is no need for any new lambda syntax, and I don't propose any. the compiler already automatically creates a block from standard lambda syntax in a .mm file...all that works great. What is needed is a directive to tell the compiler to generate a function that will invoke a method with a set of correctly typed arguments. basically...tell the compiler to create a lambda function that does a perfect forwarding to the objc method. once you have that, you can easily stuff a selector invocation inside a std::function or std::packaged_task in the usual manner.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">something like this...</div><div class=""><br class=""></div><div class="">std::packaged_task< int (cTest*, NSString*) > tmpTask( @lambda( -[cMyClass methodUsingString:] ) );<br class="">auto tmpCFuture = tmpTask.get_future();<br class=""><br class="">auto tmpCPtr = [[[cTest alloc] init] autorelease];<br class=""><br class="">tmpTask( tmpCPtr, @"hello world" );<br class=""><br class="">auto tmpResult = tmpCFuture.get();<br class=""><br class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The objc++ compiler works pretty well and is very thorough in integrating the objc world into the c++ world. there are just holes in its capabilities here and there that need to be filled.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>