C++/carbon

Najdorf Wrote:For some reason deprecated functions are always easy to use and work perfectly, while the non-deprecated version is usually a mess. It's like "no, dude, this is way too easy, be a man and do it the hard way".

ThemsAllTook Wrote:If this is actually the case with any current Apple API and not just a baseless generalization, you should file a bug report with Apple about it.

Its a generalization but it's not baseless, very often deprecated functions are replaced by more complex generalized functions which are harder to use. Alright I wasn't completely serious still I believe there's some truth in this.

I seem to recall that happening with Carbon from time to time. I haven't seen that happen very often with Cocoa though. The worst that comes to mind might be something like you can't just use getCString anymore, it has to be cStringUsingEncoding. Not really a big deal. They have the Cocoa API pretty-well thought out.

AnotherJake Wrote:Yeah, I always use UTF8String anyway. getCString was just a lame little example that came to mind.

I'd argue that this is an example of good deprecation. You preserve the earlier, easier interface with the getUTF8String function, while you give more functionality to users who need it through the new getCString. Meanwhile, the new name for the old functionality is more descriptive and tells you exactly what encoding it's using.

Oh yeah, I completely agree. I was just thinking back to when I was using getCString way back in the day and had to change it to specify the encoding when they deprecated it. Turns out they did it for a darn good reason, but it seemed like a pain in the butt at the time before I learned better. Then later I figured out I could just use UTF8String.

AnotherJake Wrote:- Apple's official word is that they recommend using Cocoa for all new applications. However, I have not seen them specifically express *disapproval* of Carbon, other than by the action of not carrying Carbon forward into the 64-bit future (at least specifically with the UI), and not adding significant new features to it. So it sure appears to be deprecated when looking at it from a common sense standpoint, but it isn't *officially* deprecated by Apple as far as I've seen.

Only parts of Carbon are left out in 64-bit, namely the GUI parts (like HIViews and Menu Manager). That is of course significant, but a whole pile of other code that are usually considered Carbon stuff are 64-bit. Those parts are not to be avoided in any way.

Ingemar Wrote:Only parts of Carbon are left out in 64-bit, namely the GUI parts (like HIViews and Menu Manager). That is of course significant, but a whole pile of other code that are usually considered Carbon stuff are 64-bit. Those parts are not to be avoided in any way.

If there are things still left which require Carbon, then yeah, obviously you have to use it, although I haven't personally had to use any Carbon for a very long time now. As to whether it should be avoided or not is obviously up to the developer. As has already been said, what's there in 32-bit will be supported for now, and they seem to intend to continue that support. However, it should be pointed out that Apple does have a record of changing their mind. Take the Carbon 64-bit UI for example: they said it would be there, then changed their mind just before the conference and dropped support for it.

Another thing to keep in mind with games is that interfacing with the OS isn't something that we have to do all that much -- at least not for performance intensive tasks where Cocoa's messaging overhead might be costly. It's mostly needed for things like windowing and menus, and some file stuff and other basic support. All of those tasks are easily done using only Cocoa. And again, staying with Cocoa makes things much easier when porting to iPhone, since Carbon is not available there. So there are a lot of compelling reasons to recommend using Cocoa, but I can't really think of any compelling reasons to use Carbon.

When people (including, frequently, Apple) say "Carbon" they generally mean the UI bits, so "don't use Carbon for new code" *is* a useful phrase.

Pointing to a useful bit of non-deprecated "Carbon" functionality is difficult, and even if you succeed, it's likely to be a case of "use this one function", not a case of "this is a whole framework you'll use extensively".