Question

J'écris une application graphique utilisant Objective-C pour le front-end et C ++ pour le traitement graphique et la communication réseau. J'ai lu sur le site d'Apple pour trouver un moyen de lier un .dylib ou un .so contenant mon code C ++ à mon projet Xcode, mais rien ne semblait fonctionner. J'ai pu faire en sorte que le projet fasse référence à ce projet, mais lorsque j'ai essayé d'appeler des fonctions à partir de ce fichier .dylib, il disait qu'il ne savait pas ce que j'essayais de faire. Est-ce que quelqu'un sait ce qui se passe ici?

Je sais qu’Objective-C dispose de toutes les bibliothèques dont j’aurais besoin pour faire de la graphique et du réseautage, mais j’ai juste envie de le faire comme ça. Je n'ai pas fait beaucoup de C ++ depuis un moment et je veux en savoir plus sur Objective-C, alors quoi de mieux que de les utiliser ensemble?

Merci, Robbie

Était-ce utile?

La solution

Vous allez rencontrer un obstacle sous la forme de ce que l'on appelle "nom mangling". C ++ stocke les noms de fonction d’une manière non compatible avec Obj-C.

Objective-C n'implémente pas les classes de la même manière que C ++, donc ça ne va pas l'aimer.

Une solution consiste à implémenter un ensemble de fonctions C simples qui appellent les fonctions C ++. Ce sera un bon défi de garder le nombre de fonctions C aussi bas que possible! Vous allez vous retrouver avec une belle interface compacte! :)

Pour déclarer ces fonctions dans un fichier C ++, vous devez les marquer en tant que C avec:

extern "C" int function_name(char *blob,int number, double foo) {...}

Ceci désactive le changement de nom standard.

Créez un fichier d’en-tête avec les prototypes de toutes ces fonctions que vous pouvez partager avec votre code C objectif.

Vous ne pourrez pas transmettre les classes de la même manière (car votre code ObjC ne peut pas les utiliser), mais vous pourrez également faire passer des pointeurs (même si vous devez mentir un peu sur les types ).

Autres conseils

La plupart des projets sur lesquels je travaille ont un frontend ObjC et un backend C ++. Si vous travaillez exclusivement avec des fonctions, le nom mangle fix de Dave Gamble est correct, mais si vous faites face à des situations plus complexes, où vous devez gérer à la fois des objets ObjC et C ++, le mieux est d'encapsuler les objets C ++. dans les objets ObjC. En utilisant des références opaques (ce qui est une manière très élégante de dire void * ), vous pouvez en fait transférer des objets C ++ dans ObjC et inversement. J'ai un exemple de code qui peut être utile.

Cela dit, pour les graphismes, vous allez probablement subir de gros problèmes de performances en utilisant du C ++ personnalisé plutôt que d'utiliser Core Image et les frameworks associés. Core Image et les autres infrastructures graphiques sont hautement optimisés pour le Mac. Il est donc très peu probable que vous fassiez mieux avec du C ++ roulé à la main (ou même du C ++ très bien écrit qui n’est pas spécifiquement conçu pour le Mac). Lorsque vous passerez à 10.6 et à la répartition centrale, la différence de performances sera encore plus marquée, car vous perdrez toutes les avancées en matière de parallélisation que vous obtiendriez gratuitement autrement. Cela n'a rien à voir avec ObjC; Core Image is C. Vous pouvez l’appeler à partir de C ++ à votre guise. Je déconseille simplement le traitement graphique personnalisé sur Mac dans n’importe quelle langue, sauf si vous avez besoin de portabilité ou si vous avez l’expertise nécessaire pour battre Core Image.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top