Cocoa vs Carbon ?

Discussion in 'Mac Programming' started by fab5freddy, Jan 12, 2009.

  1. fab5freddy macrumors 65816


    Jan 21, 2007
    Heaven or Hell
    I am rather new to programming and want to know
    what the difference between Cocoa and Carbon are ?

    thanks !
  2. TuffLuffJimmy macrumors G3


    Apr 6, 2007
    Portland, OR
    carbon isn't 64bit and is going to be killed off sooner or later. Stick with cocoa.
  3. neonblue2 macrumors 6502a

    Aug 25, 2006
    Port Pirie, South Australia
  4. kainjow Moderator emeritus


    Jun 15, 2000
    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.
  5. hhas macrumors regular

    Oct 15, 2007
    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.
  6. semicolons macrumors newbie

    Feb 14, 2008
    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.
  7. kainjow Moderator emeritus


    Jun 15, 2000
    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.
  8. Soulstorm macrumors 68000


    Feb 1, 2005
    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.
  9. Krevnik macrumors 68040


    Sep 8, 2003
    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.
  10. hhas macrumors regular

    Oct 15, 2007
    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.
  11. Catfish_Man macrumors 68030


    Sep 13, 2001
    Portland, OR
    I wonder if this fact will ever stop making me happy. I doubt it :)
  12. iAppleseed macrumors regular

    May 11, 2011
    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?
  13. ArtOfWarfare macrumors G3


    Nov 26, 2007
    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?
  14. throAU macrumors 603


    Feb 13, 2012
    Perth, Western Australia
    Carbon is deprecated - don't think Mountain Lion will run it?
  15. gnasher729, May 1, 2012
    Last edited: May 1, 2012

    gnasher729 macrumors P6


    Nov 25, 2005
    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.
  16. ArtOfWarfare macrumors G3


    Nov 26, 2007
    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.
  17. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    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?
  18. Sydde macrumors 68020


    Aug 17, 2009

    perhaps? It looks like it is meant to be a cross-platform API layer.

Share This Page