Sie können eine Cocoa-Anwendung nicht vollständig in C ++ schreiben. Cocoa verlässt sich bei vielen seiner Kerntechnologien wie Schlüsselwertbindungen, Delegierten (Kakao-Stil) und dem Zielaktionsmuster stark auf die späten Bindungsfunktionen von Objective-C. Die späten Bindungsanforderungen machen es sehr schwierig, die Cocoa-API in einer zur Kompilierungszeit gebundenen, typisierten Sprache wie C ++ implement zu implementieren. Sie können natürlich eine reine C ++ - App schreiben, die unter OS X ausgeführt wird. Die Cocoa-APIs können einfach nicht verwendet werden.
Sie haben also zwei Möglichkeiten, wenn Sie Code zwischen C ++ - Apps auf anderen Plattformen und Ihrer Cocoa-basierten Anwendung freigeben möchten. Die erste besteht darin, die Modellebene in C ++ und die GUI in Cocoa zu schreiben. Dies ist ein gängiger Ansatz, der von einigen sehr großen Apps verwendet wird, einschließlich Mathematica . Ihr C ++ - Code kann unverändert bleiben (Sie benötigen keine "funky" Apple-Erweiterungen, um C ++ unter OS X zu schreiben oder zu kompilieren). Ihre Controller-Schicht wird wahrscheinlich Objective-C ++ verwenden (möglicherweise die "funky" Apple-Erweiterung, auf die Sie sich beziehen). Objective-C ++ ist eine Obermenge von C ++, genau wie Objective-C eine Obermenge von C. In Objective-C ++ können Sie [some-objc-object callMethod];innerhalb einer C ++ - Funktion Aufrufe zum Weiterleiten von Nachrichten im Objektstil (wie ) ausführen . Umgekehrt können Sie C ++ - Funktionen aus dem ObjC-Code heraus aufrufen, z.
@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
Sie können mehr über Objective-C ++ in der Objective-C - Sprache herausfinden Führung . Die Ansichtsebene kann dann reines Objective-C sein.
Die zweite Option ist die Verwendung eines plattformübergreifenden C ++ - Toolkits. Der QtToolkit könnte die Rechnung passen. Plattformübergreifende Toolkits werden von Mac-Benutzern im Allgemeinen verachtet, da sie nicht alle Details des Erscheinungsbilds genau richtig wiedergeben und Mac-Benutzer eine Verbesserung der Benutzeroberfläche von Mac-Anwendungen erwarten. Qt leistet jedoch überraschend gute Arbeit und kann je nach Zielgruppe und Verwendung Ihrer App gut genug sein. Darüber hinaus verlieren Sie einige der OS X-spezifischen Technologien wie Core Animation und einige QuickTime-Funktionen, obwohl die Qt-API ungefähr ersetzt wird. Wie Sie hervorheben, wird Carbon nicht auf 64-Bit portiert. Da Qt auf Carbon-APIs implementiert ist, mussten Trolltech / Nokia Qt auf die Cocoa-API portieren, um die 64-Bit-Kompatibilität zu gewährleisten. Mein Verständnis ist, dass die nächste Veröffentlichung von Qt (derzeit in Release Candiate)) schließt diesen Übergang ab und ist unter OS X 64-Bit-kompatibel. Wenn Sie an der Integration von C ++ und den Cocoa-APIs interessiert sind, sollten Sie sich die Quelle von Qt 4.5 ansehen.
ⁱ Für eine Weile stellte Apple die Cocoa-API Java zur Verfügung, aber die Bridge erforderte umfangreiche Hand-Tuning und war nicht in der Lage, die oben beschriebenen fortschrittlicheren Technologien wie Key-Value-Bindungen zu verarbeiten. Derzeit dynamisch typisierte, an die Laufzeit gebundene Sprachen wie Python, Ruby usw. sind die einzige echte Option zum Schreiben einer Cocoa-App ohne Objective-C (obwohl diese Bridges natürlich Objective-C unter der Haube verwenden).