http://forums.macrumors.com/showthread.php?t=313988

Thought this was interesting.

Doesn't sound like it really impacts games. Carbon-based games will still continue to run, and I get the impression from that discussion that a game wouldn't really benefit much from 64-bit anyway.

That said, I believe SDL's XCode project templates are Cocoa-based. So if your game uses SDL, it sounds like it could probably be made to support 64-bit if needed.

Maybe not at the moment, but as hardware progresses and games become more demanding I would assume that games would benefit from 64-bit.

It's not like it's going to break backward compatibility. Does anyone even find using Carbon preferable for games?

64-bit code on Core 2 is often substantially faster than 32-bit code, so it may well make a difference, particularly to gamers.

Not, I think, that anyone seriously uses Carbon

I'm confused. Can you use the 64 bit cocoa api with the c/c++ programming language?

From my understanding, in 10.5, yes.

You can't* program Cocoa from C or C++, only ObjC (and Python, Ruby, C#, etc.). Of those, I don't know whether any but ObjC will support 64-bit out-of-the-box. You can definitely program 64-bit apps with Cocoa and ObjC though.

* well (as "unknown" will probably pop in to say), you *can* if you try hard enough, but you don't *want* to.

So what you're saying is Apple is telling the whole c/c++ community to go fly a kite if they want to develop 64 bit apps on Leopard? This is why I'm confused.

According to rumors, that is.

Not "rumors", quotes from Apple engineers on Apple mailing lists.

A good summary of the info we have is here: http://www.carbondev.com/site/?page=64-bit+Carbon

You can use C and C++ all you like still, of course, you just won't be able to make 64-bit GUI apps without dipping into ObjC to call the Cocoa APIs you need. It's not like ObjC is difficult, or like mixing it with either C or C++ is difficult, so it won't be a problem except for people who already have large Carbon code-bases like Adobe and Microsoft.

Is that so? Interesting. And great, it's a strong message to all developers to get off the Carbon train already. Then again, the link OSC posted points out that parts of Carbon will be in 64-bit, and that people with other needs should contact Apple's Framework evangelist and tell him "what and why".

From what I understand (which is quite a bit more than before since WWDC), 64-bit applications get little to no benefit over 32-bit applications if they don't need to address more than 4 GB of memory at a time. If you think about it, how often do you actually need to do that in an application?

I can imagine this moment is one that Steve has been waiting for for many years now -- he finally gets to deliver a major death blow to the old Apple code, and replace it with the fruits of Next.

Seriously though, it really does make sense. I would guess that the vast majority of developers making new products are Cocoa based. The only serious developers that still use Carbon are the ones insisting on maintaining dinosaur era apps. This is a perfect point in time to say the dinosaurs don't get to come along in some way. They still get full speed (for the most part) and full functionality, they just won't get 64 bits until they dig their collective head out of their rear-end. In all fairness, I don't personally know how much it would cost for a big software product (like Photoshop) to be re-written in Cocoa up-front vs. just continuing maintaining Carbon, but I can imagine that in the long-run it'd save big bucks.

ThemsAllTook Wrote:From what I understand (which is quite a bit more than before since WWDC), 64-bit applications get little to no benefit over 32-bit applications if they don't need to address more than 4 GB of memory at a time. If you think about it, how often do you actually need to do that in an application?

That may be true, but as far as I know, the x86 64-bit architecture is a significant improvement over the old 32-bit architecture, so on Intel Macs, 64-bit applications might run faster even if they don't need to access that much memory.

Edit: I just saw that OneSadCookie already posted something like that.