Objective-C ou C ++ pour les jeux iOS?

18

Je suis assez confiant en programmation en Objective-C et C ++, mais je trouve que Objective-C est un peu plus facile à utiliser et de nature plus flexible et dynamique.

Quels seraient les avantages et les inconvénients de l'utilisation de C ++ au lieu d'Obj-C pour écrire des jeux sur iOS? Ou plutôt, y a-t-il des problèmes connus avec l'utilisation d'Obj-C par rapport à C ++?

Par exemple, je soupçonne qu'il pourrait y avoir des problèmes de performances avec Obj-C par rapport au code écrit en C / C ++.

Martin Wickman
la source
Une question similaire a été posée sur SO
bobobobo

Réponses:

21

Un gros avantage du C ++: si vous décidez de le faire, il sera relativement facile de porter sur Android / PC / DS / PSP / (insérer la plate-forme de choix ici). Objective-C vous enfermera dans iOS jusqu'à ce que vous décidiez de réécrire tout le jeu.

ZorbaTHut
la source
10
Je ne suis pas d'accord avec le mot «facile». "Possible" peut être un meilleur choix.
3Dave
1
Oui, pour de nombreux jeux plus petits (par exemple la plupart des jeux iPhone), il est préférable de simplement tout réécrire à partir de zéro pour la nouvelle plate-forme plutôt que d'essayer d'adapter le code d'une plate-forme pour travailler sur une autre. Une architecture MVC solide minimiserait cette douleur, mais qui s'embêterait avec ça pour un match-3?
jhocking
3
Relativement facile! Si l'alternative est impossible, alors "extrêmement difficile" est relativement facile;)
ZorbaTHut
blog.vucica.net/2011/06/… il parle de la création d'applications Objective C pour Android. C'est juste Linux et Linux peut exécuter Objc aussi facilement qu'un iPhone.
Feloneous Cat
L'utilisation de l'objectif c ne vous enfermera pas. L'utilisation de fonctions spécifiques au noyau XNU le fera. Gclang est là pour une raison.
16

Il n'y a pas de réels avantages ou inconvénients ici, du moins aucun qui devrait obliger un programmeur à l'aise dans une langue à utiliser l'autre.

La performance ne devrait pas être un problème. Il est peu probable que vous écriviez un gros travail avec beaucoup de messages dans les boucles internes si vous êtes un bon programmeur Obj-C, ce qui signifie que vous allez vraiment écrire ces boucles internes en C. Si vous n'êtes pas un faible programmeur de niveau, il y a de fortes chances que le gros du travail soit fait par les bibliothèques que vous avez choisies de reporter cela aussi, et vous serez à la merci de tout ce qu'ils auront choisi de faire.

La portabilité est un vrai problème, si vous vous en souciez. Sinon, alors meh. Être multiplateforme n'est pas la fin de tout. Réussir un premier serait bien :) Vous pouvez toujours porter plus tard. Si vous ne prévoyez pas soigneusement d'être multiplateforme dès le premier jour, le fait d'être dans la même langue ne vous mènera pas très loin: il existe de nombreuses autres différences réelles entre les plates-formes qui doivent être adressées.

Terminer le projet est plus important que de s'inquiéter de la technologie, et si vous êtes plus productif à Obj-C, restez à Obj-C.

Ma préférence? Je suis un gars en C ++. Je aime Obj-C très bien, mais je suis heureux en C ++, et je fais le code multi - plateforme d'écriture.

Chris Subagio
la source
5
Je suis tout à fait d'accord avec les conseils pour se concentrer sur la finition du projet avec les outils avec lesquels vous êtes le plus productif. Éviter l'optimisation prématurée ne s'applique pas seulement à l'écriture de code, c'est un bon moyen d'approcher la vie.
jhocking
4

Il n'y a aucun problème de performances avec Obj-C sur C ++. Les deux sont du code compilé, et rappelez-vous que Obj-C est un sur-ensemble de C, et Obj-C ++ est un sur-ensemble de C ++, ce qui est idéal lorsque vous souhaitez mélanger Obj-C et C ++ dans le même programme (facile à faire et XCode a un bon support pour le côté C ++). Toutes les combinaisons de langues prennent en charge OpenGL, donc tout travail graphique sérieux est très bien et le support de la bibliothèque est correct avec Apple quelle que soit la langue.

Cela dit, quel est le but de votre jeu?

  • Si vous écrivez uniquement pour IOS, ne vous inquiétez pas et écrivez dans la langue ou la combinaison dans laquelle vous vous sentez plus à l'aise. Pour moi, cela se trouve être Obj-C ++ avec STL car c'est ma partie préférée de C ++. Comme je préfère légèrement Obj-C à C ++, j'ai tendance à utiliser cette option.

  • Si vous écrivez dans le but de porter sur un autre appareil, écrivez en C ++ avec une couche de traduction vers Obj-C pour gérer tout ce qui est spécifique à l'appareil (graphiques, entrée, caméra, ...), où les appels sont effectués vers points d'entrée dans votre application.

  • Si vous êtes le plus pur et que vous ne voulez qu'une seule langue, écrivez en obj-c.

D'autres ont parlé d'autres bibliothèques (physique et autres). Il n'y a absolument aucun problème à accéder à tout cela à partir des choix de langue dont vous parlez (Obj-C, C ++ ou Obj-C ++). Vous n'aurez également aucun problème de performances avec ces bibliothèques dans n'importe quelle langue.

Une mise en garde: il y a un appel d'indirection de pointeur avec passage de message. Je ne sais pas combien vous pouvez interpréter cela comme des frais généraux, car je suis presque sûr que c'est exactement la même chose qu'un appel de méthode C ++ hérité. Quelqu'un peut-il clarifier cela?

J'espère que cela pourra aider,

Lee.

Lee
la source
1
De bons points, mais voudriez-vous vraiment écrire votre Vector3Dclasse en Obj-C? Mon instinct me dit que cela pourrait conduire à de mauvaises performances.
Martin Wickman
1
C'est ça. Obj-C est C. Pas un problème de performances. Si vous accédez aux fichiers d'en-tête standard avec XCode, vous constaterez que les types sous-jacents ne sont que des structures C.
Lee
2
La surcharge de messages avec Obj-C est un peu plus élevée que C ++ car elle est plus dynamique. Ce n'est certainement pas "exactement la même chose". par exemple: voir developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/…
Andy Dent
1

Cela dépend exactement de ce que vous programmez. Si c'est principalement une logique de jeu utilisant des moteurs physiques et graphiques existants, je peux dire en toute sécurité que je ne vois aucune raison d'utiliser c ou c ++ si vous êtes plus à l'aise avec obj-c. Si vous allez déployer des classes de rendu ou de physique, j'écrirais probablement celles utilisant c ou c ++. Cocos2d - qui est une merveilleuse et l'une des bibliothèques de jeux iOS les plus populaires est écrite en obj-c.

Consultez cette lecture - la partie pertinente est la "division du travail", pourrait vous aider à décider quand coder dans une langue de niveau supérieur et quand utiliser un niveau inférieur: Code géré dans les jeux

Bien que la surcharge objective-c ne devrait pas être proche de C # et ne soit même pas gérée (sur iOS), je pense que la logique s'applique toujours, et les appareils exécutant iOS ne sont également pas aussi puissants que le PC qui interpréterait MSIL :)

Zaky German
la source
2
Obj-C n'est pas du code managé sur iOS. Par exemple (et en particulier) Obj-C a un garbage collector lors de la programmation pour OSX, mais il n'a pas de garbage collector sur iOS.
jhocking
@jhocking je n'ai jamais dit qu'il était géré, n'y a-t-il pas encore des frais généraux lors de l'utilisation de obj-c par opposition à c ++? J'ai mentionné c # vs c ++, c'était
Zaky German
Lorsque vous publiez un lien appelé "Managed Code in Games" tout en parlant d'Obj-C, je suppose que cela signifie que vous pensez qu'Obj-C est du code managé. Ce qui est sur OSX, mais pas sur iOS. Un peu maladroit, comme si Java était compilé en code machine sur certaines plates-formes mais fonctionnait en JVM sur d'autres.
jhocking
oh et je ne sais pas si Obj-C a des frais généraux par rapport à C ++. C'est pourquoi je ne poste pas de réponse moi-même.
jhocking
1
@jhocking no sir :) "Le problème est que le modèle de conservation / libération d'Objective-C est à peu près un compromis entre l'absence de gestion de la mémoire et un GC de base, vous êtes donc déjà en avance." interfacelab.com/objective-c-memory-management-for-lazy-people
Zaky Allemand
1

Cette étude indique que pour vraiment obtenir les performances dans un jeu intensif en CPU, vous devez utiliser C. L'article lié est complet avec un projet XCode que vous pouvez exécuter.

Je crois que l' essentiel est: Utilisez Objective-C où vous devez interagir avec les fonctions de l'iPhone (après tout, mettre des trampolines partout ne peut être bon pour personne ), mais en ce qui concerne les boucles, des choses comme les classes d'objets vectoriels ou intensives accès aux baies, respectez les tableaux C ++ STL ou C pour obtenir de bonnes performances.

Je veux dire que ce serait totalement idiot de voir position = [[Vector3 alloc] init] ;. Vous demandez simplement un résultat de performance si vous utilisez des comptages de références sur des objets de base comme un vecteur de position.

Voir aussi ces comparaisons,

comparaisons

bobobobo
la source
Votant? S'il vous plaît, expliquez.
bobobobo