J'ai parcouru le livre The livre moderne C ++ Design de Andrei Alexandrescu et il semble des choses intéressantes. Cependant, il utilise très complet des modèles et j'aimerais savoir si cela devrait être évité si vous utilisez C ++ pour le développement de la plate-forme mobile (Brew MP, Webos, IOS, etc.) en raison de considérations de taille.
dans Symbian OS C ++ L'utilisation standard des modèles est découragée, le système d'exploitation Symbian elle-même les utilise, mais à l'aide d'un idiome connu sous le nom de modèles minces où la mise en oeuvre sous-jacente est effectuée dans un style C à l'aide de vides * Pointants avec une matrice mince en haut de cela pour atteindre la sécurité de type. La raison pour laquelle ils utilisent cet idiome par opposition à l'utilisation régulière des modèles est spécifiquement pour éviter les ballonnements de code.
Alors, quelles sont les opinions (ou les faits) sur l'utilisation de modèles lors du développement d'applications de plates-formes mobiles.
5 Réponses :
Allez-y et utilisez des modèles partout où ils rendent votre code plus facile à comprendre et à entretenir. L'évitement des modèles sur les plates-formes mobiles peut être classé comme "optimisation prématurée".
Si vous rencontrez des problèmes de taille exécutable, puis redessinez si nécessaire, mais ne commencez pas avec l'hypothèse que les modèles causeront des problèmes avant de voir des problèmes réels.
Beaucoup de choses dans "la conception moderne C ++" et des livres similaires ne conduiront pas à un code ballonné, car il est tellement de choses conçues pour assurer la sécurité de type et faire de la magie de métaprogramming de compilation, plutôt que de générer code.
Les modèles peuvent être utilisés pour faire beaucoup de choses différentes. Ils peuvent générer plus de code que prévu, mais ce n'est pas une raison d'interdire leur utilisation. Il n'y a pas si longtemps que diverses autorités ont recommandé d'éviter des exceptions, des fonctions virtuelles, des mathématiques à virgule flottante et même des classes en raison de préoccupations concernant la taille et la performance du code, mais les gens ont fait ces choses, et tout a bien fonctionné bien.
se mettre d'accord. Lorsqu'une approche modélisée est la meilleure, utilisez-la. Si cela conduit à une énorme taille binaire, il existe des moyens de refracteur pour le réduire
Clang peut également être utile, je pense qu'ils ont maintenant un certain nombre d'objectifs mobiles, mais je pourrais me tromper.
Je dirais qu'en général (pas seulement lié au développement mobile), ce conseil est titulaire. Certaines des techniques décrites dans la conception moderne C ++ peuvent conduire à des temps de construction longue et de code de code.
Ceci est particulièrement vrai lorsqu'il s'agit de dispositifs "obscur", comme les téléphones cellulaires. De nombreuses techniques de modèles reposent sur le fait que le compilateur et la lieur font un travail parfait pour éliminer le code inutilisé / en double. S'ils ne le font pas, vous risquez de disposer de centaines de buts en double Cela ne veut pas dire que la conception moderne C ++ est un mauvais livre ou que les modèles sont mauvais. Mais surtout sur des projets intégrés, il est préférable de surveiller, car il peut mordre. std :: vecteur instances dispersées sur votre code. Et croyez-moi, j'ai vu cela arriver.
Sur une note latérale, quelqu'un peut-il recommander des livres "similaires" C ++ à celui-ci qui ne sont pas si lourds sur l'utilisation de modèles? (J'ai déjà efficacement C ++).
Vous voulez dire un livre sur l'utilisation de modèles pour créer des versions génériques de plusieurs modèles de conception courants qui n'utilisent pas fortement les modèles?
Modèle MetaProgramming fait peur à la Bejayzus de moi, mais "Normes de codage C ++" est un excellent livre de Sutter et Alexandrescu.
Quoi que vous fassiez, n'essayez pas d'écrire du code, de la compiler et de comparer la taille ou la duplication de code exécutable.
Dans mon expérience personnelle en utilisant des modèles (et même abuser) entraîne très rarement rarement dans le grand flucteur de code et la compilation avec Ce n'est pas si commun de voir d'énormes classes de gabarits Dupliqués (instanciées) plusieurs fois, les deux, car les classes rarement sont énormes , et parce que dans la plupart des cas, vous seul instanciez les modèles avec quelques arguments différents, pas des centaines . En outre, il est facile de réutiliser du code commun dans vos plus grandes classes / fonctions de modèle et votre compilateur vous aidera à le faire.
Taille habituellement de données (graphiques, audio, ...) est des commandes de grandeur plus grandes que le code. Donc, je ne m'inquiéterais pas.
Bien sûr, il pourrait y avoir des exceptions à ce que j'ai dit, mais je suppose qu'ils seront surtout sur avancé ( spécial / bizarre / complexes ) trucs, pas avec les classes quotidiennes les plus courantes.
Résumer ma suggestion: utilisez des modèles autant que vous le souhaitez, si quelque chose va mal, vous le découvrirez en profilant, et vous pourrez facilement optimiser la taille. -Os aidera beaucoup.
Les modèles ne conduisent pas nécessairement à Code BLOAT. Si vous écrivez un modèle de fonction ou de classe et instanciez-le pour une douzaine de types différents, vous obtenez beaucoup de code de dupliqué généré (probablement, de toute façon. Certains compilateurs peuvent fusionner des instanciations identiques).
Mais si un modèle est instancié pour un type uniquement, il y a alors zéro coût de la taille du code. Si vous l'instanciez plusieurs fois, vous payez un certain coût, mais vous finiriez également de payer si vous avez utilisé les autres moyens d'obtenir la même chose. Le polymorphisme dynamique (fonctions virtuelles et héritage) n'est pas gratuit non plus. Vous payez pour cela en termes de vtales, code généré pour faciliter toutes les moules et conversions de type nécessaires, et simplement en raison du code qui ne peut pas être inlincé ou optimisé.
prise Le problème principal avec l'utilisation de modèles est qu'il nécessite un compilateur qui le supporte. Sur un PC, ce n'est pas un problème. Sur toute autre plate-forme qui a un compilateur mature C ++ disponible, ce n'est pas un problème.
Mais toutes les plates-formes ne disposent pas d'un compilateur moderne Heavy-Duty C ++ disponible. Certains ne prennent pas en charge un certain nombre de fonctionnalités avancées, et certains ne sont tout simplement pas suffisamment bons aux optimisations nécessaires pour faire fonctionner le code de modèle (les modèles ont tendance à nécessiter beaucoup d'inlinité, par exemple). Donc sur certaines plates-formes, il peut être préférable d'éviter les modèles. Non pas en raison de toute préoccupation pour la taille du code, mais parce que le compilateur peut être incapable de le gérer. std :: vecteur comme exemple, alors oui, si vous utilisez les deux vectoriel vecteur vecteur vecteur
C'est vraiment le C2.com/cgi/wiki?suffirySmartCompiler Syndrome. Il existe de nombreuses techniques très intelligentes C ++ nécessitant un compilateur suffisamment intelligent. Mais dans le champ intégré, de tels compilateurs sont vraiment rares. Habituellement, ils font juste ce que vous le dites à faire - ce qui est dans de nombreux cas pour générer un gros tas de code gonflé.
Si je peux reformuler cela - il existe de très nombreuses optimisations de compilateur que mai se produisent - et beaucoup de techniques intelligentes C ++ qui supposent que ces optimisations se produisent. Juste pour nommer une telle technique - optimisation de la valeur de retour. S'ils rencontrent un compilateur qui ne fait pas cette optimisation, le code fonctionnera soudainement vraiment mauvais. L'élimination du code qui ne se produit pas peut être un problème encore pire pour les modèles.
Sauf dans ce cas, nous ne parlons pas de "élimination du code qui n'arrive pas", mais à propos de "code qui n'est jamais généré en premier lieu". La norme garantit que les modèles ne sont pas instanciés tant que vous les instanciez. Un compilateur qui a essayé d'instancier le code de modèle qui n'a pas été appelé (par exemple, chaque fonction d'un modèle de classe, au lieu de simplement celles utilisées) pourraient rencontrer des erreurs de compilation et rejeter votre programme C ++ parfaitement valide. Ce serait une erreur pour qu'un compilateur génère du code pour des modèles jamais instanciés.
Dupliqué possible de Quand le modèle instanciation de BLOAT est-il en pratique?
+1, je ne savais pas de modèles minces.
Même sur des appareils mobiles, la taille EXE ne signifiera rien que d'autres supports tels que des images, du texte, des sons. Comme toujours, profilez en premier et n'opiez pas prématurément.