Supposons que je développe une application Mac ou iOS typique à l'aide des derniers outils Xcode d'Apple. Supposons en outre que je développe principalement cette application à l'aide de l'objectif-C et de tirer profit de toutes les API pertinentes des cadres de cacao ou de cacao d'Apple.
Disons que je n'ai pas actuellement aucun projet d'utiliser C ++ ou Objective-C ++ dans ma base de code, mais je soupçonne que quelque temps à l'avenir, je pourrait envie de saupoudrer dans un peu Objective-C ++ ici un là.
Alors je envisage de nommer tous mes fichiers Est-ce une mauvaise idée? Y a-t-il une raison pour que l'utilisation de fichiers Vraisemblablement, cette extension de fichier retourne un interrupteur dans le compilateur qui devra analyser le code source pour non seulement l'objc, mais également C ++. Cela a-t-il un effet négatif important sur les temps de construction pour des bases de code modéré à grandes?
a-t-il d'autres effets négatifs (ou positifs) que je devrais garder à l'esprit?
Remarque: veuillez ne pas répondre avec des commentaires sur le point de savoir si OBJC ou C ++ est meilleur. Ce n'est pas la question de cette question. .m comme .mm au cas où. (Cela aura l'effet souhaitable d'une histoire plus propre dans mon système SCM, car je n'ai pas à renommer des fichiers plus tard.)
.mm est définitivement ou significativement pire que d'utiliser .m lorsque le fichier ne contient aucun objectif-c ++?
6 Réponses :
Citation de Barry Wark:
L'inconvénient majeur à utiliser .mm sur .m pour "normal" objectif-c Est-ce que les temps de compilation sont nettement plus élevés pour l'objectif-C ++. Cette est que le compilateur C ++ prend plus de temps que le compilateur C. Avec Xcode 3.2 et supérieur, le code Objective-C peut utiliser l'outil de frontage de clang chaîne pour accélérer de manière significative les temps de compilation de l'objectif-C / C. Puisque Clang ne supporte pas encore Objective-C ++ / C ++, cela élargit davantage la écart en cas de compilation entre les deux.
mais
Mise à jour du 17 février 2012 à partir de Xcode 4.0 (avec LLVM 3.0), Clang a Objective-C ++ pris en charge. Même C ++ 11 Support est assez fort maintenant.
Donc, je pense que c'est correct à utiliser .mm tant que si vous utilisez uniquement des fonctionnalités C, les fichiers .mm doivent générer du code qui fonctionne très similaire à .m
Oui, quand je jette un coup d'oeil au bâtiment Connexion Xcode. Tout le fichier Objective-C prend moins de 1 seconde à construire. Un fichier avec 1180 lignes de code prend 0,9 seconde pour construire dans le journal de construction Xcode. Cependant, en général, les fichiers mm et C ++ sont plus longs. Un fichier mm avec 400 lignes de code prend environ 4,8secondes.
.mm Extension signifie fichier Objective-C ++. Le compilateur prend plus de temps pour compiler C ++ Code que C Code C.
Donc, si ce n'est pas nécessaire, gardez l'extension comme .m uniquement.
Ce n'est pas la pire idée, mais ce n'est pas vraiment une bonne idée, non plus.
L'objectif principal de l'objectif-C ++ est d'agir en tant que pont pour le code Objective-C qui doit utiliser une bibliothèque C ++. Ainsi, dans la plupart des projets, la quasi-totalité du code est la simple objectif d'objectif, avec peut-être quelques fichiers .mm pour créer un objet "wrapper" pour parler à la bibliothèque C ++.
Par conséquent, il est extrêmement improbable que vous deviez modifier des parties importantes de votre code sur l'objectif-C à l'objectif-C ++. Vous ne devriez pas avoir beaucoup de fichier renommé de votre histoire SCM.
Le principal problème avec l'utilisation de l'objectif-C ++ partout est que vous suivrez "la route moins fréquentée": 99% des tutoriels que vous avez lu et open source de code que vous utilisez et apprennent de toutes les personnes seront écrites pour être compilées par le compilateur Obj-C. L'utilisation du compilateur OBJ-C ++ sera la plupart de la même façon et ne fera probablement pas la différence la plupart du temps, mais vous finirez par courir dans un problème due à l'obj-C ++ étant compilé légèrement différemment, mais lorsque vous trouvez le Bug Ce n'est pas évident, et vous passerez beaucoup de temps à essayer de le diagnostiquer avant de vous rendre compte que c'est que vous utilisez une configuration de compilateur moins testée.
Si vous avez beaucoup d'expérience C ++ et que vous trouvez des fonctionnalités "besoin" de C ++ dans votre code, vous n'avez probablement pas vraiment besoin d'eux, vous devez probablement passer un peu plus de temps à comprendre comment faire l'équivalent Objectif c. Quand à Rome, faites comme les Romains.
En général, "juste au cas où" n'est pas une bonne raison de s'écarter de la pratique standard. Vous avez souvent fini de dépenser beaucoup d'efforts sur quelque chose que vous n'allez pas avoir besoin.
C'est le genre d'expertise que je recherche. Excellente réponse. Merci Benzado.
de mon expérience (à Apple): 1) L'équipe XCODE pense à propos de C ++ dernier (a pris pour toujours pour obtenir la prise en charge des blocs à Objc ++) 2) objc ++ est beaucoup plus lent dans la compilation
Ce n'est pas que l'équipe Xcode pense que C ++ en dernier, c'est que faire n'importe quoi avec C ++ est sur une commande de grandeur plus complexe et difficile que d'assumer!
Dans ce cas, Kiss dicterait que vous évitez Obj-C ++ jusqu'à ce que vous en ayez absolument besoin. En passant: quel type de VCS utilisez-vous qui ne peut pas gérer facilement le fichier renommé? Svn / git / hg tous les travaux sont assez bien lorsque vous renommez des fichiers.
Oui, c'est une mauvaise idée.
Quand je vois un fichier Nomez tous vos fichiers de votre objectif-c comme Vous obtenez des points bonus si vous conservez vos fichiers d'en-tête C ++ - moins. .mm , je m'attends à ce qu'il ait CODE C ++ (en plus de l'objectif-c bien sûr). Il y a quelques éléments qui ne sont pas directement liés à l'OOP qui sont un peu différents en C ++ comparant à c.
.m . Dès que vous avez besoin de fonctionnalités C ++ - renommez-la à .mm et vérifiez que tout fonctionne.
Comme je l'ai écrit dans un commentaire, C ++ n'est pas un superset strict de C, il est donc possible que vous conduisiez dans des cas où vous utilisez par exemple. Code C99 qui ne compilera pas si vous le mettez dans un fichier Objective-C ++. J'ai eu ce problème récemment à l'aide de C99 littéraux composés .
Cela devrait vous aider Stackoverflow.com/questions/2317868/...
Notez que C ++ n'est pas un superset strict de C, il est donc possible de courir dans des cas où vous utilisez par exemple. Code C99 qui ne compilera pas si vous le mettez dans un fichier Objective-C ++.
@echristopherson c'est un point assez important. Vous devriez le mettre dans une bonne réponse. :)
Compiler comme Objc ++ limite votre gamme de noms de variables potentiels, car vous n'êtes pas autorisé à utiliser des mots réservés de C ++. Par exemple, vous ne pouvez pas nommer des choses de variables comme "opérateur" ou "nouveau".