Nie można napisać aplikacji Cocoa w całości w języku C ++. Cocoa w dużym stopniu opiera się na późnych możliwościach wiązania Objective-C w przypadku wielu podstawowych technologii, takich jak powiązania klucz-wartość, delegaci (styl kakaowy) i wzorzec działania docelowego. Wymagania dotyczące późnego wiązania bardzo utrudniają implementację interfejsu API Cocoa w języku typizowanym związanym z czasem kompilacji, takim jak C ++ ⁱ. Możesz oczywiście napisać aplikację w czystym języku C ++ działającą na systemie OS X. Po prostu nie może ona korzystać z API Cocoa.
Masz więc dwie opcje, jeśli chcesz udostępniać kod między aplikacjami C ++ na innych platformach i aplikacją opartą na kakao. Pierwszym jest napisanie warstwy modelu w C ++ i GUI w Cocoa. Jest to typowe podejście stosowane przez niektóre bardzo duże aplikacje, w tym Mathematica . Twój kod C ++ może pozostać niezmieniony (nie potrzebujesz "funky" rozszerzeń Apple, aby pisać lub kompilować C ++ na OS X). Twoja warstwa kontrolera prawdopodobnie będzie korzystać z Objective-C ++ (być może "funky" rozszerzenia Apple, o którym mówisz). Objective-C ++ jest nadzbiorem C ++, tak jak Objective-C jest nadzbiorem C. W Objective-C ++, można tworzyć komunikaty w stylu objc, przekazujące wywołania (na przykład [some-objc-object callMethod];) z poziomu funkcji C ++. I odwrotnie, możesz wywoływać funkcje C ++ z poziomu kodu ObjC, na przykład:
@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
Możesz dowiedzieć się więcej o Objective-C ++ w przewodniku po języku Objective-C . Warstwa widoku może wtedy być czystą Objective-C.
Drugą opcją jest użycie wieloplatformowego zestawu narzędzi C ++. Plik Qtzestaw narzędzi może pasować do rachunku. Wieloplatformowe zestawy narzędzi są generalnie pogardzane przez użytkowników komputerów Mac, ponieważ nie zapewniają one wszystkich szczegółów wyglądu i dotyku, a użytkownicy komputerów Mac oczekują dopracowania w interfejsie aplikacji na komputery Mac. Qt wykonuje jednak zaskakująco dobrą robotę i w zależności od odbiorców i sposobu użytkowania aplikacji może być wystarczająco dobry. Ponadto stracisz na niektórych technologiach specyficznych dla OS X, takich jak Core Animation i niektóre funkcje QuickTime, chociaż istnieją przybliżone zamienniki w Qt API. Jak zauważyłeś, Carbon nie zostanie przeniesiony do wersji 64-bitowej. Ponieważ Qt jest zaimplementowany w Carbon API, Trolltech / Nokia musiało przenieść Qt do Cocoa API, aby było kompatybilne z 64-bitowym. Rozumiem, że następne wydanie Qt (obecnie kandydat do wydania) kończy to przejście i jest kompatybilny z 64-bitowym systemem OS X. Możesz rzucić okiem na źródło Qt 4.5, jeśli jesteś zainteresowany integracją C ++ i API Cocoa.
ⁱ Przez jakiś czas Apple udostępniło API Cocoa dla Javy, ale most wymagał obszernego dostrajania ręcznego i nie był w stanie obsłużyć bardziej zaawansowanych technologii, takich jak opisane powyżej wiązania klucz-wartość. Obecnie dynamicznie wpisywane języki związane ze środowiskiem uruchomieniowym, takie jak Python, Ruby itp., Są jedyną realną opcją pisania aplikacji Cocoa bez Objective-C (chociaż oczywiście te mosty używają Objective-C pod maską).