We used an object database called NeoAccess for our 32-bit C++ app. It had reference counting for objects retrieved from the database. Setting the ref count manually was extremely easy to screw up. It was hard to debug off-by-ones on the ref count. So we made those calls private, and replaced them all with a stack-based watcher class. It adds a reference in the constructor, and removes it in the destructor. Simpler, more reliable, and exception-safe.
It makes sense that Cocoa programmers much prefer ARC to MRC. Doing it manually is easy to break and hard to debug. However, the fact that ARC is not exception-safe concerns me. It suggests that Cocoa still manages ref counts manually, somewhere under the hood. We've had two sets of mystery deallocs that both involved NSTabView. From hard past experience, I would bet there is a bug lurking somewhere inside there. In fact, assuming that Cocoa is written entirely in plain C, it may not even be possible to avoid manual ref counts. No STL, no RAII, no native exceptions. It makes sense to write kernels in C because speed is important. But GUI frameworks are way more complex, and C may just not be the right tool for them. I'm no fan of garbage collection, but those languages do make programming easier. There's enough other stuff to worry about. It's why Java & Python are so popular. C++ makes the programmer fully responsible for memory, but the modern STL really helps. It's improving rapidly. Even when C++ breaks, it's easy to debug object lifetimes. Just put a breakpoint in the destructor. If it's dying too soon you'll see exactly what killed it. If a leak it will never get there. Our company sells to construction companies. Our expertise is in accounting, estimating and other construction business tasks. We need a platform that lets us create apps quickly. Cocoa is not that. We've spent 3 years so far on 64-bit porting via Cocoa. Best guess is another year or 2 to get it perfect. Meanwhile, we should be adding features to keep up with the Windows competition. I don't know if anyone from Apple is on this list, but I think Cocoa needs a huge overhaul. It's 30 years old and showing its age. The problem is not just memory management. The constraint system is extremely difficult- we've spent many days futzing with it, and there are still mystery problems. Pretty much everything else is more creaky and awkward than it could be. Swift may be the solution, but it's built on a weak foundation. It makes cross-platform development almost impossible. The TIOBE index shows Swift declining (and Objective-C increasing). So, maybe it isn't. It would really help if programmers could write Macintosh apps in C++, Python, etc. Casey McDermott TurtleSoft.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
