Re: Thoughts on ARC
Re: Thoughts on ARC
- Subject: Re: Thoughts on ARC
- From: Richard Charles via Cocoa-dev <email@hidden>
- Date: Fri, 27 Sep 2019 10:20:47 -0600
> On Sep 27, 2019, at 6:19 AM, Turtle Creek Software via Cocoa-dev
> <email@hidden> wrote:
>
> 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.
Traditional Cocoa manual memory management relies on naming conventions and
just a few basic rules. When combined with the Xcode static analyzer it is
almost pain free. However it is not as Swift as latest thing.
> 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.
Objective-C is plain C with a runtime and a few syntactic additions. The big
and beautiful thing about Cocoa are frameworks which are written in Objective-C
and now Swift.
> 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.
It appears like your biggest challenge is porting a 32-bit C++ third party
library and porting Carbon to Cocoa? Moving from 32 bit Cocoa to 64 bit Cocoa
should not be a big deal.
What I wish Apple would do is release a cross platform Objective-C (and Swift)
solution. They already transitioned from PowerPC to Intel and ARM. iTunes at
one time was released for Windows. One programmer almost did this single
handedly with the Cocotron. It was so well written and comprehensive that
Microsoft picked it up and started using it for their WinObjC framework. The
Mac vs Windows war is over and long gone so why doesn’t Apple help out the
small developer and release a cross platform solution.
> 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.
Apple did a language overhaul with Swift. My primary app requires integration
with C++ so I have stuck with Objective-C and Objective-C++ and the traditional
Cocoa frameworks.
--Richard Charles
_______________________________________________
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
| References: | |
| | >Thoughts on ARC (From: Turtle Creek Software via Cocoa-dev <email@hidden>) |