Thoughts on ARC
Thoughts on ARC
- Subject: Thoughts on ARC
- From: Turtle Creek Software via Cocoa-dev <email@hidden>
- Date: Fri, 27 Sep 2019 08:19:19 -0400
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 (email@hidden)
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:
This email sent to email@hidden