Sont inutilisés comprend nocif en C/C++?

Question

Quelles sont les conséquences négatives de inutilisés comprend?

Je suis conscient qu'ils entraîner une augmentation de la taille du binaire (ou le font-ils?), quelque chose d'autre?

Answer 1

• Augmente le temps de compilation (potentiellement grave problème)
• Pollue espace de noms global.
• Le potentiel de conflit de préprocesseur noms.
• Si inutilisé en-têtes sont inclus à partir de bibliothèques de tiers, il peut faire de telles bibliothèques inutilement maintenu comme des dépendances.

Answer 2

Ils n'ont pas nécessairement augmenter la taille du binaire, mais augmentera les temps de compilation.

Answer 3

Le principal problème est l'encombrement. Ce sont les trois aspects principaux qui le désordre se manifeste:

1. La pollution visuelle; pendant que vous êtes à essayer de comprendre les autres comprend que vous avez besoin.

2. Logique de la pollution; il est plus probable d'avoir de collision de fonctions, plus de temps pour la compilation (ce pourrait être vraiment petite pour un couple de comprend, mais si elle devient une "politique" pour ne pas le nettoyage inutiles comprend, il pourrait devenir un obstacle important).

3. La dépendance de l'opacité; depuis il y a plus de têtes à analyser est-il difficile de déterminer la dépendance de cycles dans votre code. Savoir quelles sont les dépendances dans votre code est crucial lors de votre base de code augmente significativement le niveau au-delà de l'amateur.

Answer 4

Généralement parlant, oui, cela pose quelques problèmes. Logiquement, si vous n'en avez pas besoin, alors ne pas l'inclure.

• Tous les singletons déclaré comme externe dans un en-tête et défini dans un fichier source sera inclus dans votre programme. Cela augmente évidemment l'utilisation de la mémoire et contribue peut-être à une surcharge de performance en causant un pour accéder à leur page de fichier le plus souvent (pas beaucoup d'un problème, maintenant, que les singletons sont généralement de petite à moyenne taille, et parce que la plupart des gens que je connais ont+ de 6 GO de RAM).

• Le temps de Compilation est augmenté, et pour les grands projets commerciaux où l'on compile souvent, cela peut entraîner une perte d'argent. Il peut seulement ajouter quelques secondes à votre temps total, mais multipliez-le par la de plusieurs centaines de compile ou alors, vous pourriez avoir besoin de tester et de déboguer et vous avez un énorme gaspillage de temps, ce qui se traduit donc par une perte de profit.

• La plus les en-têtes que vous avez, plus la chance que vous pouvez avoir une avenante collision avec une macro que vous avez défini dans votre programme ou un autre en-tête. Ceci peut être évité par l'utilisation correcte des espaces de noms, mais c'est toujours chiant à trouver. Encore une fois, la perte de profit.

• Contribue à l'augmentation du code (les fichiers les plus longs et donc plus à lire) et peut fortement augmenter le nombre de résultats que vous trouvez dans votre IDE de l'auto outil complet (certaines personnes sont religieusement à l'encontre de ces outils, mais ils ne augmenter la productivité dans une certaine mesure).

• Vous pouvez accidentellement lien d'autres bibliothèques externes dans votre programme sans même le savoir.

• Vous risquez de provoquer la fin du monde en faisant cela.

Answer 5

Je pars du principe que les en-têtes peuvent tous être considérés comme des "sincère", qui est, ne sont pas précisément écrit dans le but de saboter votre code.

• Il sera généralement lente de la compilation (les en-têtes précompilés permettra d'atténuer ce point)

• il implique des dépendances où aucun n'existe pas (c'est une erreurs de sémantique, pas d'erreur)

• les macros vont polluer votre code (atténué par la préfixation de macros avec l'espace de noms-comme les noms, comme dans BOOST_FOREACH au lieu de FOREACH)

• un en-tête pourrait sous-entendre un lien vers une autre bibliothèque. dans certains cas, un solde non utilisé de l'en-tête pourrait demander à l'éditeur de liens pour lier votre code avec une bibliothèque externe (voir MSCV de la directive#pragma comment(lib, "")). Je crois qu'un bon éditeur de liens ne garderait pas la bibliothèque de référence si elle n'est pas utilisée (IIRC, MSVC de l'éditeur de liens ne gardera pas la référence d'un inutilisés de la bibliothèque).

• la suppression d'un en-tête est un de moins source de bugs imprévu. si vous n'avez pas confiance dans l'en-tête (certains codeurs sont mieux que d'autres...), puis de l'enlever supprime un risque (vous n'aimez pas ce dont un en-tête de la modification de la structure de l'alignement de tout ce qui est après elle : la réalisation de bugs... éclairant...).

• un en-tête de l' static déclaration de variable va polluer votre code. Chaque variable statique déclaration de résultat dans une variable globale déclarée dans votre source compilé.

• C symbole noms de polluer votre code. Les déclarations dans l'en-tête de polluer votre global ou structure d'espace de noms (et plus probablement, à la fois, comme les structures sont généralement typedef-ed d'apporter leur type dans l'espace de noms global). Ceci est atténué par les bibliothèques de la préfixation de leurs symboles avec une sorte de "nom d'espace de noms", comme SDL_CreateMutex pour la SDL.

• non-préfixée C++ symbole noms de polluer votre code. Pour les mêmes raisons que ci-dessus. Il en va de même pour les en-têtes prendre la mauvaise utilisation de l' using namespace déclaration. Maintenant, corriger C++ code de l'espace de noms de ses symboles. Oui, cela signifie que vous ne devez généralement pas confiance à un en-tête C++ déclarer ses symboles dans l'espace de noms global...