Vous ne pouvez pas écrire une application Cocoa entièrement en C ++. Cocoa s'appuie fortement sur les capacités de liaison tardive d'Objective-C pour bon nombre de ses technologies de base telles que les liaisons clé-valeur, les délégués (style Cocoa) et le modèle d'action cible. Les exigences de liaison tardives rendent très difficile l'implémentation de l'API Cocoa dans un langage typé lié à la compilation comme C ++ ⁱ. Vous pouvez, bien sûr, écrire une application C ++ pure qui s'exécute sur OS X. Elle ne peut tout simplement pas utiliser les API Cocoa.
Ainsi, vous avez deux options si vous souhaitez partager du code entre des applications C ++ sur d'autres plates-formes et votre application basée sur Cocoa. La première consiste à écrire la couche de modèle en C ++ et l'interface graphique en Cocoa. Il s'agit d'une approche courante utilisée par certaines très grandes applications, y compris Mathematica . Votre code C ++ peut rester inchangé (vous n'avez pas besoin d'extensions Apple "funky" pour écrire ou compiler du C ++ sous OS X). Votre couche de contrôleur utilisera probablement Objective-C ++ (peut-être l'extension Apple "funky" à laquelle vous faites référence). Objective-C ++ est un sur-ensemble de C ++, tout comme Objective-C est un sur-ensemble de C. En Objective-C ++, vous pouvez faire des messages de style objc en passant des appels (comme [some-objc-object callMethod];) à partir d'une fonction C ++. Inversement, vous pouvez appeler des fonctions C ++ à partir du code ObjC comme:
@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
Vous pouvez en savoir plus sur Objective-C ++ dans le guide du langage Objective-C . La couche de vue peut alors être pure Objective-C.
La deuxième option consiste à utiliser une boîte à outils C ++ multiplateforme. Le Qtboîte à outils pourrait convenir. Les boîtes à outils multiplateformes sont généralement méprisées par les utilisateurs de Mac car elles n'obtiennent pas tous les détails de l'apparence et de la convivialité et les utilisateurs de Mac s'attendent à ce que l'interface utilisateur des applications Mac soit polie. Cependant, Qt fait un travail étonnamment bon et en fonction du public et de l'utilisation de votre application, cela peut être suffisant. De plus, vous perdrez certaines des technologies spécifiques à OS X telles que Core Animation et certaines fonctionnalités QuickTime, bien qu'il existe des remplacements approximatifs dans l'API Qt. Comme vous le faites remarquer, Carbon ne sera pas porté en 64 bits. Depuis que Qt est implémenté sur les API Carbon, Trolltech / Nokia ont dû porter Qt sur l'API Cocoa pour le rendre compatible 64 bits. Je crois comprendre que la prochaine version de Qt (actuellement en version) complète cette transition et est compatible 64 bits sous OS X. Vous voudrez peut-être jeter un œil à la source de Qt 4.5 si vous êtes intéressé par l'intégration de C ++ et des API Cocoa.
ⁱ Pendant un certain temps, Apple a rendu l'API Cocoa disponible pour Java, mais le pont a nécessité un réglage manuel approfondi et n'a pas été en mesure de gérer les technologies plus avancées telles que les liaisons clé-valeur décrites ci-dessus. Les langages actuellement typés dynamiquement et liés à l'exécution comme Python, Ruby, etc. sont la seule véritable option pour écrire une application Cocoa sans Objective-C (bien que ces ponts utilisent bien sûr Objective-C sous le capot).