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 nombre de ses technologies de base, telles que les liaisons clé-valeur, les délégués (style Cocoa) et le modèle cible-action. Les exigences en matière de liaison tardive font que très difficile d'implémenter l'API Cocoa dans un langage typé lié à la compilation comme le C++. Vous pouvez, bien sûr, écrire une application C++ pure qui fonctionne sous OS X. Elle ne peut simplement pas utiliser les API Cocoa.
Vous avez donc deux options si vous souhaitez partager du code entre des applications C++ sur d'autres plateformes et votre application basée sur Cocoa. La première consiste à écrire la couche modèle en C++ et l'interface graphique en Cocoa. Il s'agit d'une approche courante utilisée par certaines applications de très grande taille, dont les suivantes Mathematica . Votre code C++ peut rester inchangé (vous n'avez pas besoin des extensions "funky" d'Apple pour écrire ou compiler du C++ sous OS X). Votre couche contrôleur fera probablement appel à 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 appels au passage de messages de type objc (comme [some-objc-object callMethod]; ) à l'intérieur d'une fonction C++. Inversement, vous pouvez appeler des fonctions C++ à partir du code ObjC, par exemple :
@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 trouverez plus d'informations sur l'Objective-C++ dans la section consacrée au langage Objective-C. guide . La couche de visualisation peut alors être en Objective-C pur.
La deuxième option consiste à utiliser une boîte à outils C++ multiplateforme. Le site Qt pourrait faire l'affaire. Les boîtes à outils multiplateformes sont généralement méprisées par les utilisateurs de Mac parce qu'elles n'offrent pas une apparence et une convivialité parfaites et que les utilisateurs de Mac s'attendent à ce que l'interface utilisateur des applications Mac soit polie. Cependant, Qt fait un travail étonnamment bon, et selon le public et l'utilisation de votre application, cela peut être suffisant. De plus, vous perdrez certaines technologies spécifiques à OS X telles que Core Animation et certaines fonctionnalités de QuickTime, bien qu'il existe des remplacements approximatifs dans l'API Qt. Comme vous le soulignez, Carbon ne sera pas porté en 64 bits. Comme Qt est implémenté sur les API de Carbon, Trolltech/Nokia ont dû porter Qt sur l'API Cocoa pour le rendre compatible avec le 64 bits. D'après ce que j'ai compris, la prochaine version de Qt (actuellement en cours d'élaboration) sera compatible 64 bits. candidat à la libération ) achève cette transition et est compatible 64 bits sous OS X. Vous pouvez jeter un coup d'œil aux sources 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 mis l'API Cocoa à la disposition de Java, mais le pont nécessitait un réglage manuel important et était incapable de gérer les technologies plus avancées telles que les liaisons clé-valeur décrites ci-dessus. Actuellement, les langages 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 passerelles utilisent évidemment Objective-C sous le capot).
