Est-ce une mauvaise idée d'utiliser des fichiers .mm au lieu de .m, au cas où j'utiliserais C++ plus tard ?

Question

Supposons que je développe une application Mac ou iOS typique à l'aide des derniers outils Xcode d'Apple. Supposons également que je développe principalement cette application à l'aide d'Objective-C et que j'exploite toutes les API pertinentes des cadres Cocoa ou Cocoa Touch d'Apple.

Disons que je n'envisage pas actuellement d'utiliser C++ ou Objective-C++ dans ma base de code, mais que je pense qu'un jour ou l'autre je pourrait vous voulez saupoudrer un peu d'Objective-C++ ici et là.

Donc j'envisage de nommer toutes mes .m comme .mm à la place, juste au cas où. (Cela aura l'effet souhaitable d'un historique plus propre dans mon système SCM, car je n'aurai pas à renommer les fichiers plus tard).

Est-ce une mauvaise idée ? Y a-t-il une raison pour laquelle l'utilisation de .mm est définitivement ou significativement pire que d'utiliser .m alors que le fichier ne contient pas d'Objective-C++ ?

On peut supposer que cette extension de fichier déclenche un interrupteur dans le compilateur qui devra alors analyser le code source non seulement pour ObjC, mais aussi pour C++. Cela a-t-il un effet négatif significatif sur les temps de construction pour les bases de code de taille moyenne à grande ?

A-t-il d'autres effets négatifs (ou positifs) que je devrais garder à l'esprit ?

REMARQUE : veuillez ne pas répondre par des commentaires sur la question de savoir si ObjC ou C++ est meilleur. Ce n'est pas le sujet de cette question.

Answer 1

Ce n'est pas la pire idée, mais ce n'est pas vraiment une bonne idée non plus.

L'objectif principal d'Objective-C++ est de servir de passerelle pour le code Objective-C qui doit utiliser une bibliothèque C++. Ainsi, dans la plupart des projets, la quasi-totalité du code est du bon vieil Objective-C, avec peut-être quelques fichiers .mm pour créer un objet "wrapper" permettant de communiquer avec la bibliothèque C++.

Il est donc très peu probable que vous ayez à modifier des parties importantes de votre code pour passer d'Objective-C à Objective-C++. Vous ne devriez pas avoir beaucoup de renommages de fichiers dans votre historique SCM.

Le principal problème de l'utilisation de l'Objective-C++ partout est que vous suivrez "le chemin le moins fréquenté" : 99% des tutoriels que vous lirez et du code open-source que vous utiliserez et dont vous tirerez des enseignements seront tous écrits pour être compilés par le compilateur Obj-C. L'utilisation du compilateur Obj-C++ sera essentiellement la même, et ne fera probablement pas de différence la plupart du temps, mais vous finirez par rencontrer un problème dû à la compilation légèrement différente d'Obj-C++, mais lorsque vous trouverez le bogue, il ne sera pas évident, et vous passerez beaucoup de temps à essayer de le diagnostiquer avant de réaliser que c'est parce que vous utilisez une configuration de compilateur moins bien testée.

Si vous avez une grande expérience du C++ et que vous vous retrouvez à avoir "besoin" de fonctionnalités du C++ dans votre code, vous n'en avez probablement pas vraiment besoin, vous devez probablement passer un peu plus de temps à trouver comment faire l'équivalent en Objective-C. Quand vous êtes à Rome, faites comme les Romains.

En général, le "juste au cas où" n'est pas une bonne raison de s'écarter de la pratique standard. Vous finissez souvent par dépenser beaucoup d'efforts pour quelque chose dont vous n'aurez pas besoin.

Answer 2

Comme je l'ai écrit dans un commentaire, le C++ n'est pas un sur-ensemble strict du C, il est donc possible que vous rencontriez des cas où vous utilisez par exemple du code C99 qui ne compilera pas si vous le mettez dans un fichier Objective-C++. J'ai eu ce problème récemment en utilisant du C99 littéraux composés .

Answer 3

Citation de Barry Wark :

Le principal inconvénient de l'utilisation de .mm au lieu de .m pour l'Objective-C " normal " est que les temps de compilation sont nettement plus élevés pour l'Objective-C++. est que les temps de compilation sont nettement plus élevés pour l'Objective-C++. Ce Ceci est dû au fait que le compilateur C++ prend plus de temps que le compilateur C. Avec Xcode 3.2 et plus, le code Objective-C peut utiliser la chaîne d'outils frontale Clang pour s'adapter à l'évolution du code. pour accélérer de manière significative les temps de compilation d'Objective-C/C. Depuis Clang ne supportant pas encore Objective-C++/C++, l'écart entre les deux compilateurs se l'écart de temps de compilation entre les deux.

MAIS

MISE À JOUR 17 février 2012 À partir de Xcode 4.0 (avec LLVM 3.0), Clang a supporté Objective-C++. Même le support de C++11 est maintenant assez fort.

Je pense donc qu'il n'y a pas de problème à utiliser des fichiers .mm tant que si vous n'utilisez que des fonctions C, les fichiers .mm devraient générer du code dont les performances sont très similaires à celles des fichiers .m.

Answer 4

Oui, c'est une mauvaise idée.

Quand je vois un .mm je m'attends à ce qu'il contienne du code C++ (en plus de l'Objective-C bien sûr). Il y a quelques choses qui ne sont pas directement liées à la POO et qui sont un peu différentes en C++ par rapport au C.

Nommez donc tous vos fichiers Objective-C comme .m . Dès que vous avez besoin d'une fonctionnalité C++, renommez-la en .mm et vérifiez que tout fonctionne.

Vous obtenez des points bonus si vous gardez vos fichiers d'en-tête sans C++.

Answer 5

D'après mon expérience (chez Apple) : 1) l'équipe xcode pense au c++ en dernier (il a fallu une éternité pour obtenir le support des blocs dans objc++) 2) objc++ est beaucoup plus lent à compiler