i'm not sure that it's that direct. Carbon was apples way of describing programming that was basically the same as in the pre-unix, Classic environment, but had been reconfigured to run natively in OSX
Cocoa is completely native to OSX, and has no left over relation to the old Classic days.
Carbon is old, but familiar and compatible, Cocoa is new, modern and powerful.
iTunes and the Finder are still carbon, things like iPhoto, messenger and Garageband are in cocoa.
characteristics of cocoa are that cocoa will respect the placement of the dock, and resizing using the + button actually works. also the Application menu is more contextual.
i'm not an actual programmer, so i'm going to get corrected.
Carbon is a library, which is very similar to Win32 (i.e. Windows) code. It is what most cross platform applications use, since as Lt Major Burns says, it is more familiar to developers. You can call it from C, C++, and probably other languages. That said, it is _not_ a language.
Cocoa is a library that is usable from Objective-C or Java. It's more 'modern', and kinda integrates better with the OS. Things like automatic spell checking in a text box (like the one I'm typing in now) are only available in Cocoa apps, not Carbon. This is just one example of how Cocoa seems better integrated into the OS. The 'look' of Cocoa applications adheres better to the OS X guidelines, mainly because the changes to the OS X interface (for some reason) do not always apply to Carbon applications.
If you want to port a C++ application from Windows, you will most likely want to concentrate on Carbon. However, I have a better suggestion. Since you are talking about bringing a C++ application over from Windows, the chances are high that it is written in MFC. If it is, you should stay away from Carbon and Cocoa. Instead you should us wxWidgets. It is similar to MFC, and it is cross platform, running on anything from Palm OS, to OS X.
wxWidgets is a good option because it actually uses native controls and doesn't emulate them, like Qt or Java Swing does. The benefit of that is your app looks great, and behaves great too . On OS X, you even have the option of using either Cocoa or Carbon controls.
So if you are thinking of porting a Windows C++ app that was written using MFC, you really must look at wxWidgets. For a moderately sized application (approx 10,000 lines), you may even get it ported in under a day.
Actually, Cocoa is based around Objective-C, not C++. Carbon is built for C and C++, and if you're porting from Windows, you'll probably find it easier to work with Carbon.
That said, there are definite advantages to working with Cocoa, and if a lot of your logic is already written in C++, that's okay, because you can mix C++ into your Cocoa/Objective-C programs pretty seamlessly (this hybrid language is called Objective-C++).
Most of what Burns said is true, at least in practice. Cocoa apps are usually much cleaner and more "OS X-like". Most of the time you CAN mimic in Carbon the functionality normally associated with Cocoa, but few programmers do, because it takes a lot of extra work, whereas in Cocoa, you get it all "for free".
Sure lots of them. What are you trying to do? If this is really a background task then you could just target the BSD layer and basically get Unix/Linux compatibility for free.
It really depends on what you need. Files and networking -- BSD is you friend. Interfacing with the Keychain and Authorization Services -- you will need to use Objective-C and Core Foundation (if you value your sanity). Also keep in mind that you are free to mix and match C, C++, and Objective C along with BSD, Carbon and Cocoa. So it might be best to just write a Objective C interface to the services you need and then call that from the existing C++ code.
I guess the overall point is that you can do it almost any way you would like and you have not given enough information to identify if one way is actually going to be better than another in this situation.