Non è possibile scrivere un'applicazione Cocoa interamente in C ++. Cocoa fa molto affidamento sulle capacità di associazione tardiva di Objective-C per molte delle sue tecnologie principali come le associazioni di valori chiave, i delegati (stile Cocoa) e il modello di azione di destinazione. I requisiti di associazione tardiva rendono molto difficile implementare l'API Cocoa in un linguaggio tipizzato vincolato in fase di compilazione come C ++ ⁱ. Ovviamente puoi scrivere un'app C ++ pura che gira su OS X. Non può usare le API Cocoa.
Quindi, hai due opzioni se desideri condividere il codice tra le app C ++ su altre piattaforme e la tua applicazione basata su Cocoa. Il primo è scrivere il livello del modello in C ++ e la GUI in Cocoa. Questo è un approccio comune utilizzato da alcune app di grandi dimensioni, tra cui Mathematica . Il tuo codice C ++ può essere lasciato invariato (non hai bisogno di estensioni Apple "funky" per scrivere o compilare C ++ su OS X). Il livello del tuo controller probabilmente farà uso di Objective-C ++ (forse l'estensione "funky" di Apple a cui ti riferisci). Objective-C ++ è un superset di C ++, proprio come Objective-C è un superset di C. In Objective-C ++, puoi effettuare chiamate di passaggio di messaggi in stile objc (come [some-objc-object callMethod];) dall'interno di una funzione C ++. Al contrario, puoi chiamare funzioni C ++ dall'interno del codice ObjC come:
@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
Puoi trovare ulteriori informazioni su Objective-C ++ nella guida al linguaggio Objective-C . Il livello di visualizzazione può quindi essere puro Objective-C.
La seconda opzione è utilizzare un toolkit C ++ multipiattaforma. Il Qtil toolkit potrebbe adattarsi al conto. I toolkit multipiattaforma sono generalmente disprezzati dagli utenti Mac perché non ottengono tutti i dettagli dell'aspetto e delle funzionalità esattamente giusti e gli utenti Mac si aspettano un tocco di lucentezza nell'interfaccia utente delle applicazioni Mac. Qt fa un lavoro sorprendentemente buono, tuttavia, e a seconda del pubblico e dell'uso della tua app, potrebbe essere abbastanza buono. Inoltre, perderai alcune delle tecnologie specifiche di OS X come Core Animation e alcune funzionalità QuickTime, sebbene ci siano sostituzioni approssimative nell'API Qt. Come fai notare, Carbon non sarà portato a 64 bit. Poiché Qt è implementato sulle API Carbon, Trolltech / Nokia ha dovuto portare Qt all'API Cocoa per renderlo compatibile a 64 bit. La mia comprensione è che la prossima versione di Qt (attualmente in rilascio candiate) completa questa transizione ed è compatibile a 64 bit su OS X. Potresti voler dare un'occhiata ai sorgenti di Qt 4.5 se sei interessato a integrare C ++ e le API Cocoa.
ⁱ Per un po 'di tempo Apple ha reso disponibile l'API Cocoa per Java, ma il bridge ha richiesto un'estesa messa a punto manuale e non è stata in grado di gestire le tecnologie più avanzate come le associazioni valore-chiave descritte sopra. Attualmente, linguaggi runtime-bound tipizzati dinamicamente come Python, Ruby, ecc. Sono l'unica vera opzione per scrivere un'app Cocoa senza Objective-C (sebbene ovviamente questi bridge utilizzino Objective-C sotto il cofano).