What are the trade-offs for using Carbon vs. Cocoa considering a developer with about 15 years of programming experience already in C/C++.
Is Carbon a dead end with OS X?
+23
A:
It seems that the whole situation is a bit complicated, but while Carbon may not be a complete dead end for Mac OS X development, if you're new to developing for the Mac, I can't see why you would start with anything other than Cocoa.
TimB
2008-09-30 04:13:34
The link in the answer appears to be broken.
staffan
2009-05-25 14:31:29
Link seems fine now.
TimB
2009-06-19 01:43:35
+2
A:
Carbon is a dead end, Apple isn't really into supporting it much more(as in how they act, as opposed to what they say), my guess is Objective-C is all they need, or maybe they're making a more modern C++ api, not like Carbon and its Win32 style api.
Oh, and the Ojective-C messaging framework is a really good solution to handle scalable multithreaded application with out complicating things or requiring programmers to think much about multithreaded issues like races and dead-locks. Actually I think that in that sense it's even superior to C# or C++, for simple application development during the next few years, until the next language revolution.
Robert Gould
2008-09-30 04:13:52
+4
A:
There are a few compelling reasons to use Carbon, but for most new code, using Cocoa will be less work overall (even including learning Objective-C). Unless you've got existing Carbon code, or you're trying to tie into an existing cross-platform UI library, you probably ought to use Cocoa.
Carbon is a "dead end" in that Apple's not adding as much new API to Carbon vs. the Cocoa frameworks. Carbon is also not supported for 64-bit programs. It's not likely that Carbon will actually cease to be supported entirely any time soon.
Mark Bessey
2008-09-30 04:14:01
"There are a few compelling reasons to use Carbon"; what are they? Explaining when Carbon is still useful would be a very useful answer to this question.
Mark Baker
2008-09-30 14:50:08
Sorry, I thought I had - if you're interfacing to an existing multi-platform UI library, or you've already got Mac code, then Carbon is for you. Otherwise, use Cocoa.
Mark Bessey
2008-09-30 15:58:03
+4
A:
You're supposed to be able to mix C, C++, and Objective-C, so you could use Cocoa purely for the UI, and write the rest in C++.
mrrage
2008-09-30 04:19:15
and there's even the Objective-C++ thing where you can use Cocoa directly from your C++ code at the expense of getting rather confused by the two incompatible object models being used simultaneously.
Mark Baker
2008-09-30 14:51:05
+2
A:
Cocoa (with Objective-C) is great for the UI.
But hat does not prevent you from mixing this with C++ for storing and manipulating the data behind the scenes.
As for Carbon. I am not sure.
I use the Objective-C and C++ in combination. Use the correct language for the correct job.
Martin York
2008-09-30 04:23:46
+5
A:
One thing to consider is iPhone portability; I think it has Cocoa APIs only.
akauppi
2008-09-30 07:29:09
+3
A:
Mac OS X developers who primarily use Cocoa still use Carbon all the time. It is a very common occurrence to have to use a carbon API when there isn't an equivalent Cocoa API.
Just think of Carbon as another tool (or rather set of tools) in your API toolbox. There's no need to play the "OMG Carbon Sucks! Cocoa rules!" game. It isn't healthy.
I'd hazard a guess that most popular Cocoa applications have a dash of Carbon in them.
The iPhone does change this a little. The iPhone SDK is (mostly) new from the ground app and Carbon wasn't included (but then so was a huge chunk of Cocoa too).
Use whatever tool allows you to do you work most efficiently and stop worrying about the whole Cocoa vs Carbon thing.
schwa
2008-09-30 19:43:21
Replace "Carbon" with "C Function based APIs" in your comment, and you are mostly correct. But every C Function based API isn't Carbon. Carbon is a event loop model environment whatchamacallit, and an app uses one or another.
benzado
2008-10-01 04:33:05