Les composants non utilisés sont-ils dangereux en C / C ++?

Quelles sont les conséquences négatives des inclusions non utilisées?

Je suis conscient que cela se traduit par une taille binary accrue (ou fait-elle?), Autre chose?

  • Augmente le temps de compilation (problème potentiellement grave)
  • Pollue l’espace de noms global.
  • Conflit potentiel des noms de préprocesseur.
  • Si des en-têtes inutilisés sont inclus à partir de bibliothèques tierces, cela peut rendre ces bibliothèques inutilement gérées en tant que dépendances.

Ils n’augmentent pas nécessairement la taille binary, mais augmenteront le temps de compilation.

Le principal problème est l’ encombrement . Ce sont les trois aspects principaux dans lesquels le fouillis se manifeste:

  1. Pollution visuelle; pendant que vous essayez de comprendre d’autres éléments dont vous avez besoin.

  2. Pollution logique; il est plus probable qu’il y ait collision de fonctions, plus de temps pour comstackr (cela peut être très petit pour quelques inclusions, mais si cela devient une «politique» pour ne pas nettoyer les éléments inutiles, cela peut devenir un obstacle important).

  3. Opacité de dépendance; Comme il y a plus d’en-têtes à parsingr, il est plus difficile de déterminer les cycles de dépendance dans votre code. Connaître les dépendances de votre code est crucial lorsque votre base de code atteint un niveau significatif au-delà du niveau amateur.

De manière générale, oui, cela pose des problèmes. Logiquement parlant, si vous n’en avez pas besoin, ne l’incluez pas.

  • Tous les singletons déclarés comme externes dans un en-tête et définis dans un fichier source seront inclus dans votre programme. Cela augmente évidemment l’utilisation de la mémoire et consortingbue probablement à une surcharge de performance en obligeant à accéder à leur fichier de pages plus souvent (pas vraiment un problème maintenant, car les singletons sont généralement de taille petite à moyenne et parce que la plupart des Go de RAM).

  • Le temps de compilation augmente, et pour les grands projets commerciaux où l’on comstack souvent, cela peut entraîner une perte d’argent. Cela ne fait qu’append quelques secondes à votre temps total, mais multipliez-le par plusieurs centaines de comstacks, vous devrez peut-être le tester et le déboguer et vous perdez énormément de temps, ce qui se traduit par une perte de profit.

  • Plus vous avez d’en-têtes, plus vous risquez d’avoir une collision prévisible avec une macro que vous avez définie dans votre programme ou dans un autre en-tête. Cela peut être évité via une utilisation correcte des espaces de noms, mais cela rest un problème à trouver. Encore une fois, perte de profit.

  • Consortingbue au code bloat (fichiers plus longs et donc plus à lire) et peut augmenter considérablement le nombre de résultats trouvés dans l’outil de saisie automatique de votre IDE (certaines personnes sont religieusement contre ces outils, mais elles augmentent la productivité dans une certaine mesure).

  • Vous pouvez accidentellement associer d’autres bibliothèques externes à votre programme sans même le savoir.

  • Vous pouvez par inadvertance causer la fin du monde en faisant cela.

Je suppose que les en-têtes peuvent tous être considérés comme “sincères”, c’est-à-dire qu’ils ne sont pas écrits avec précision dans le but de saboter votre code.

  • Cela ralentira généralement la compilation (les en-têtes pré-compilés atténueront ce point)

  • cela implique des dépendances où il n’y en a pas vraiment (c’est une erreur sémantique, pas une erreur réelle)

  • les macros pollueront votre code (atténué par le préfixe des macros avec des noms de type espace de noms, comme dans BOOST_FOREACH au lieu de FOREACH)

  • un en-tête peut impliquer un lien vers une autre bibliothèque. Dans certains cas, un en-tête inutilisé pourrait demander à l’éditeur de liens de lier votre code à une bibliothèque externe (voir #pragma comment (lib, “”) de MSCV). Je crois qu’un bon éditeur de liens ne conserverait pas la référence de la bibliothèque si elle n’est pas utilisée (l’IIRC, l’éditeur de liens de MSVC ne conservera pas la référence d’une bibliothèque inutilisée).

  • un en-tête supprimé est une source de moins de bogues inattendus. si vous ne faites pas confiance à l’en-tête (certains codeurs sont meilleurs que d’autres …), le supprimer supprime un risque ( vous n’aurez pas envie d’inclure un en-tête modifiant la structure de tout ce qui suit: éclairant … ).

  • la déclaration de variable static un en-tête pollue votre code. Chaque déclaration de variable statique se traduira par une variable globale déclarée dans votre source compilée.

  • Les noms de symbole C pollueront votre code. Les déclarations dans l’en-tête pollueront votre espace de noms global ou struct (et plus probablement les deux, car les structures sont généralement typées pour apporter leur type dans l’espace de noms global). Ceci est atténué par les bibliothèques préfixant leurs symboles avec une sorte de “nom d’espace de noms”, comme SDL_CreateMutex pour SDL.

  • les noms de symboles C ++ non placés sous un nom de fichier pollueront votre code. Pour les mêmes raisons ci-dessus. Il en va de même pour les en-têtes qui utilisent mal la déclaration using namespace . Maintenant, le code C ++ correct va nommer ses symboles. Oui, cela signifie que vous ne devriez généralement pas faire confiance à un en-tête C ++ déclarant ses symboles dans l’espace de noms global …

Qu’ils augmentent ou non la taille binary dépend vraiment de ce qu’ils contiennent.

L’effet secondaire principal est probablement l’impact négatif sur la vitesse de compilation. Encore une fois, la taille de l’impact dépend de leur contenu, de leur importance et de leur inclusion éventuelle dans d’autres en-têtes.

Pour ceux qui les quittent, il suffit de prolonger le temps de compilation et d’append des dépendances de compilation inutiles .

Ils représentent un design maladroit.

Si vous n’êtes pas sûr de savoir quoi inclure et quoi ne pas inclure, cela montre que le développeur n’avait aucune idée de ce qu’il faisait.

Les fichiers d’inclusion doivent être inclus uniquement lorsque le besoin s’en fait sentir. Ce n’est peut-être pas tant le problème car la mémoire et la vitesse de l’ordinateur augmentent à pas de géant ces jours-ci, mais c’était peut-être une fois.

Si un inclusion n’est pas nécessaire mais inclus de toute façon, je recommanderais de mettre un commentaire à côté de lui en disant pourquoi vous l’avez inclus. Si un nouveau développeur passe à votre code, il vous en sera reconnaissant, si vous l’avez fait correctement.

include signifie que vous ajoutez d’autres déclarations. Donc, lorsque vous écrivez votre propre fonction globale, vous devez faire attention à ce que cette fonction soit déjà décrite dans l’en-tête inclus.

Ex. Si vous écrivez votre propre classe auto_ptr {} sans inclure “memory”, cela fonctionnera correctement. mais chaque fois que vous allez inclure de la mémoire, le compilateur donne une erreur car il a déjà été déclaré dans le fichier d’en-tête de la mémoire

Oui, ils peuvent augmenter la taille binary en raison des variables externes non utilisées.

 //---- in unused includes ---- extern int /* or a big class */ unused_var; //---- in third party library ---- int unused_var = 13;