I am rather new to programming and want to know
what the difference between Cocoa and Carbon are ?
thanks !
what the difference between Cocoa and Carbon are ?
thanks !
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Cocoa vs Carbon ?
- Thread starter fab5freddy
- Start date
- Sort by reaction score
Yes if you're new to Mac OS X programming, skip over Carbon, at least the UI stuff. The file/alias/etc manager still applies and can be used in 64-bit but to do a UI use Cocoa.
First bit is wrong; second is speculation. Carbon's GUI APIs are 32-bit only, as are the Carbon QuickTime APIs; avoid these for new development. Most other major Carbon APIs are present on 64-bit OS X. Quite a few provide functionality that is absent or inferior in Cocoa.
For GUI work use Cocoa. For other other things you'll likely want to stay on Cocoa where practical, but don't be put off using officially supported Carbon APIs where you need them.
Avoid carbon until you need it, as Cocoa is the future. It has been recommended by Apple, for the past few years at least, that you use Cocoa for new development. Unfortunately, there are still some things you can't do in Cocoa, for which you need Carbon, but don't bother with Carbon until you need it.
Also, Cocoa is very mature at this point, but there are still things (for example) like checking to see if a key is down that don't work 100% in Cocoa. Normally you'd do this by checking [[NSApp currentEvent] modifierFlags] but NSApplication doesn't begin handling events until at a certain point, so if this in your app's awakeFromNib/init or similar methods, it won't work and you have to stick with GetCurrentEventKeyModifiers()... I have yet to find a non-Carbon workaround (since this won't let you compile 64-bit AFAIK).
Edit: I guess I didn't search hard enough last time. Here (see comments) is how you do it without Carbon using CGEventCreate() and CGEventGetFlags().
Anyways, my point is Cocoa still isn't complete yet. You may still need to use some Carbon APIs or other C-based ones that don't have an Objective-C wrapper yet.
Edit: I guess I didn't search hard enough last time. Here (see comments) is how you do it without Carbon using CGEventCreate() and CGEventGetFlags().
Anyways, my point is Cocoa still isn't complete yet. You may still need to use some Carbon APIs or other C-based ones that don't have an Objective-C wrapper yet.
One thing that hasn't been mentioned is that Carbon (not the GUI stuff) in general is Cocoa in plain C. You still get the retain/release methods and memory management in Carbon has many similarities with Cocoa. So, if you begin with Cocoa, when the time comes and you need Carbon, it won't be difficult to adapt to it.
Most of the other major Carbon APIs are present mostly because they don't predate OS X, and they are shared with Cocoa in some way (or were expected to be used by developers in both environments).
The key thing to remember is: if the API predates 10.0, or is GUI-related, it's gone. That really covers most of the important stuff required to do an application in pure C anyways.
Handbrake is probably a good example of how you can do a mixed C/Obj-C application: put your low-level code into a static library, and link it straight into an Obj-C GUI front-end. You get the portability of the core feature set, while staying on Apple's good side.
This is true for newer Carbon APIs that appeared post-OS9, e.g. Core Foundation. Pre-OSX APIs use a different memory management scheme (which isn't reference-counted, unfortunately).
Still not quite correct; if you really want to know what's on its way out, look in the header files or on Apple's developer site [1]. e.g. Two major Carbon frameworks that I [for my sins] do a lot of work with - Apple Event Manager and Open Scripting Architecture - both predate OS X and have been updated over the years to ensure OSX and 64-bit compatibility. And I'd be pretty peeved if they went away any time soon given that their Cocoa wrappers are inferior and/or not a good fit with non-ObjC-based implementations.
I imagine folk like Microsoft and Adobe who have massive investments in C++ codebases would also have an absolute fit if any more Carbon APIs go away - I don't imagine they were overly pleased about Apple's last-minute reversal on the 64-bit Carbon GUI APIs. Apple would lose significant marketshare if those vendors decided enough was enough.
--
[1] The ones I can recall offhand are all Carbon GUI, QT, QD APIs. FSSpecs and APIs that use them are also defunct; modern alternatives are provided as needed.
What the heck is Carbon and Cocoa? Oh, I know what Cocoa is. It's chocolate. But what does it have to do with Macs or Programming?
I realize this topic was just revived by a troll, but I'd like to ask a quick question regarding Carbon...
Should I avoid it like the plague, or is it still necessary to use it ever?
I'm just learning to use a 3D graphics engine (Ogre 3D) which appears to work much better with Carbon than Cocoa (cocoa will end up having artifacting for some reason where Carbon won't,) but ultimately I'd like the game I'm making with it to be sold on the Mac App Store.
So... Figure out how to make it work with Cocoa, or should I just accept the easy solution of using Carbon?
Should I avoid it like the plague, or is it still necessary to use it ever?
I'm just learning to use a 3D graphics engine (Ogre 3D) which appears to work much better with Carbon than Cocoa (cocoa will end up having artifacting for some reason where Carbon won't,) but ultimately I'd like the game I'm making with it to be sold on the Mac App Store.
So... Figure out how to make it work with Cocoa, or should I just accept the easy solution of using Carbon?
Carbon is not the "easy solution", because you will have to throw all your Carbon code out and replace it with Cocoa quite soon. Carbon is 32 bit only. It is not actively developed, which means known bugs will not be fixed. It is deprecated. I was told that you can't update your development machine to Mountain Lion.
It will still be able to run Carbon apps, but you can't develop Carbon apps on Mountain Lion. Which seems a very good indication that in 10.9 Carbon may be completely gone.
Last edited:
By "easy solution", I just meant the one that required no effort right now on my part. But, message received, stop using carbon immediately. Transition period is over; now isn't the time to be holding onto it.
I guess I need to figure out why the engine has artifacting under cocoa and fix that... doesn't sound like a fun task... not even one I know where to begin with fixing.
Does Ogre 3D have a home page? Maybe there's a newer version.
If there's not a newer version, is there a bug-report web page? Have you filed a bug there?
