Comment Re:Cocoa or Carbon? Daddy or Chips? (Score 2, Informative) 162
I've taken a look at the same problem recently.
My feeling is that while Cocoa is a better choice for developing Mac OS X specific stuff, Carbon may end up being more similar to other platforms, and so possibly a bit easier for this specific use. Cocoa is still very doable for the same problem - but essentially, I suspect many C++ methods would just end up being a call to an equivalent Cocoa method (though often one you've written yourself). Mixing C and C++ is not particularly ugly or hackish in most cases. You can more of less mix the two syntaxes easily enough with Apples Objective-C++ support.
It kind of depends on your specific libraries, though. If your libraries are such that your objects correspond fairly closely to Cocoas, you might be better off using Cocoa.
The real value of Objective-C lies in its dynamic nature, which if you were writing a cross-platform C++ library you might not be able to make much effective use of.
I wouldn't worry that Carbon is being phased out, or that there will be new shiny functionality only accessible from Cocoa. In my experience thats not really the case at all. There is definitely functionality only accessible from Carbon (and lots of it) and Carbon is quite well supported. A lot of non-GUI Cocoa stuff (FoundationKit) is more or less duplicated with CoreFoundation (which is a straight C interface, accessible from both and interoperable with corresponding Cocoa classes). Lots of important apps are written in Carbon. Carbon works well with interface builder (you end up writing a LOT of event handlers, but they are straightforward).
My feeling is that while Cocoa is a better choice for developing Mac OS X specific stuff, Carbon may end up being more similar to other platforms, and so possibly a bit easier for this specific use. Cocoa is still very doable for the same problem - but essentially, I suspect many C++ methods would just end up being a call to an equivalent Cocoa method (though often one you've written yourself). Mixing C and C++ is not particularly ugly or hackish in most cases. You can more of less mix the two syntaxes easily enough with Apples Objective-C++ support.
It kind of depends on your specific libraries, though. If your libraries are such that your objects correspond fairly closely to Cocoas, you might be better off using Cocoa.
The real value of Objective-C lies in its dynamic nature, which if you were writing a cross-platform C++ library you might not be able to make much effective use of.
I wouldn't worry that Carbon is being phased out, or that there will be new shiny functionality only accessible from Cocoa. In my experience thats not really the case at all. There is definitely functionality only accessible from Carbon (and lots of it) and Carbon is quite well supported. A lot of non-GUI Cocoa stuff (FoundationKit) is more or less duplicated with CoreFoundation (which is a straight C interface, accessible from both and interoperable with corresponding Cocoa classes). Lots of important apps are written in Carbon. Carbon works well with interface builder (you end up writing a LOT of event handlers, but they are straightforward).
