Você não pode escrever um aplicativo Cocoa inteiramente em C ++. O cacau depende muito dos recursos de vinculação tardia do Objective-C para muitas de suas principais tecnologias, como vinculações de valor-chave, delegados (estilo cacau) e o padrão de ação-alvo. Os requisitos de ligação tardia tornam muito difícil implementar a API do Cocoa em uma linguagem digitada vinculada ao tempo de compilação, como o C ++ ⁱ. Obviamente, você pode escrever um aplicativo C ++ puro que seja executado no OS X. Ele simplesmente não pode usar as APIs do Cocoa.
Portanto, você tem duas opções se desejar compartilhar código entre aplicativos C ++ em outras plataformas e seu aplicativo baseado em Cocoa. O primeiro é escrever a camada do modelo em C ++ e a GUI no cacau. Essa é uma abordagem comum usada por aplicativos muito grandes, incluindo o Mathematica . Seu código C ++ pode permanecer inalterado (você não precisa de extensões "funky" da apple para escrever ou compilar C ++ no OS X). Sua camada do controlador provavelmente fará uso do Objective-C ++ (talvez a extensão "descolada" da Apple a que você se refere). Objective-C ++ é um superconjunto de C ++, assim como Objective-C é um superconjunto de C. No Objective-C ++, você pode fazer chamadas no estilo objc passando mensagens (como [some-objc-object callMethod];) de dentro de uma função C ++. Por outro lado, você pode chamar funções C ++ de dentro do código ObjC, como:
@interface MyClass {
MyCPPClass *cppInstance;
}
@end
@implementation MyClass
- (id)init {
if(self = [super init]) {
cppInstance = new MyCPPClass();
}
return self;
}
- (void) dealloc {
if(cppInstance != NULL) delete cppInstance;
[super dealloc];
}
- (void)callCpp {
cppInstance->SomeMethod();
}
@end
Você pode descobrir mais sobre o Objective-C ++ no guia de idiomas da Objective-C . A camada de visualização pode então ser pura Objective-C.
A segunda opção é usar um kit de ferramentas C ++ entre plataformas. The Qtkit de ferramentas pode ser adequado. Os kits de ferramentas de plataforma cruzada geralmente são desprezados pelos usuários de Mac, porque não obtêm todos os detalhes de aparência e aparência exatamente corretos e os usuários de Mac esperam polimento na interface do usuário dos aplicativos Mac. No entanto, o Qt faz um trabalho surpreendentemente bom e, dependendo do público e do uso do seu aplicativo, pode ser bom o suficiente. Além disso, você perderá algumas das tecnologias específicas do OS X, como Core Animation e algumas funcionalidades do QuickTime, embora haja substituições aproximadas na API Qt. Como você aponta, o Carbon não será portado para 64 bits. Desde que o Qt é implementado nas APIs do Carbon, a Trolltech / Nokia precisou portar o Qt para a API do cacau para torná-lo compatível com 64 bits. Meu entendimento é que a próxima versão do Qt (atualmente em versão candiate) conclui essa transição e é compatível com 64 bits no OS X. Você pode dar uma olhada na fonte do Qt 4.5 se estiver interessado em integrar o C ++ e as APIs do Cocoa.
Por um tempo, a Apple disponibilizou a API Cocoa para Java, mas a ponte exigiu um amplo ajuste manual e não foi capaz de lidar com as tecnologias mais avançadas, como as Vinculações de valor-chave descritas acima. Atualmente, linguagens dinamicamente tipadas e vinculadas ao tempo de execução, como Python, Ruby etc., são a única opção real para escrever um aplicativo Cocoa sem o Objective-C (embora, obviamente, essas pontes usem o Objective-C sob o capô).