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

[John McCall via cfe-dev]

> On Mar 28, 2018, at 4:07 PM, James Gregurich <bayoubengalml at mac.com> wrote:
> 
> 
>> 
>> I think this is just a misunderstanding of what std::weak_ptr is supposed to do.  std::weak_ptr is a defined part of the std::shared_ptr system.  I would be very surprised if std::shared_ptr<NSObject> actually worked in any sensible way; if it does, it works by adding an extra level of indirection, more or less by accident.  I do not think it would be appropriate to try to special-case these templates so that they transparently just created ARC strong/weak references; I doubt that such a solution would really conform to the standard.
>> 
>> John.
> 
> Actually, I have this mechanism running in production in a live-tv environment where a crash could mean the stage goes dark in front of millions of tv viewers or the lights go out on the Superbowl halftime show. Crashes are not an option in such a circumstance. Using this mechanism, I've tracked down and eradicated a large number of long-standing memory leaks and core animation misbehaviors that caused problems in production. It is a high-quality solution to the pitfalls inherent in the objc retain/release/autorelease design pattern.  
> 
> The system runs well and allows me to have a codebase that works correctly under ARC or non-ARC with no awful macro-checking injected in the code.  I just had to jury rig a way to work around the remaining limitation of std::weak_ptr<>....which I am currently advocating to fix. You'll note that I've previously reported a bug in ARC (radar 31170126) which was fixed by Apple  that caused shared_ptr<> to misbehave and crash. If I remember correctly, when I did that analysis, the shared_ptr<> templated retains twice...once in shared_ptr itself and once more in the internals of the retain counting mechanism...which based on my reading of the ARC docs is exactly what it should do. yes, it does do an extra retain/release, but who cares. When you are utilizing the shared_ptr in such a manner, it is typically for a use where the extra retain and release has no real-world impact...such as sharing an objc object with a task to be passed off to a dispatch queue.  in the non-arc case, typically, you alloc/init a class instance and pass it off to shared_pointer...just as you would do with any raw pointer. on shared_ptr destruction, [release] is called. there is no unnecessary labor involved.  ok...there is an extra counter for a retain count built into the objc object...again one doesn't typically use shared_ptr in places where that extra cost has any real-world impact. I also note that if once is concerned about keeping a class size to an absolute minimum,  he'd be better off using a c++ class that imposed NO extra overhead rather than an objc 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.

> I'm not sure how any of this has relevance to the standard. The change I am advocating will allow a raw pointer (objc in this case) to be stored weakly in the weak_ptr instance...which is exactly what the weak_ptr is supposed to do.  Currently, the weak_ptr strongly retains by the rules of ARC because it is storing the objc pointer in a data member of a class.
> 
> 
> Note that the system works correctly out of the box when ARC is off. Even if there is disagreement over the utility of the mechanism, I content that the mechanism should work correctly out of the box regardless of the state of ARC. 

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.

John.