Dites que vous #incluez et n'utilisez jamais rien de stdio.h. Quels sont les frais généraux associés à cela? J'ai remarqué que beaucoup de code réseau incluait tous les en-têtes liés au réseau auxquels ils pouvaient penser au cas où ils finiraient par utiliser quelque chose de l'un d'entre eux, donc je me demandais si c'était une sorte de facilité d'utilisation ou d'efficacité. s'il n'y a pas de perte d'efficacité.Coût d'un #include dans C
Surcoût de compilation, principalement, car le compilateur doit inclure et analyser ce fichier.
L'inclusion de fichiers non nécessaires entraînera une légère augmentation des temps de compilation, mais n'aura aucun effet sur le code généré.
Cela devrait avoir une incidence sur la vitesse de compilation uniquement, et non sur la vitesse d'exécution. En ce qui concerne le temps de compilation, pour les grands projets, cela peut être perceptible mais la seule façon de savoir comment cela affecte vos projets est de mesurer les temps de compilation avec et sans les inclus.
Il n'y a pas de perte d'efficacité pendant l'exécution. C'est plus un problème de maintenance car le fait d'avoir des inclusions superflues rend peu claires les bibliothèques que vous utilisez réellement.
Precompiled headers Dans la plupart des compilateurs populaires de nos jours rendent les coûts d'inclusion de #include assez négligeable. Et à l'exécution rien de tout cela ne reste de toute façon puisque les linkers sont assez intelligents pour ne pas inclure des choses qui ne sont pas nécessaires.
Toute surcharge sera principalement au moment de la compilation plutôt que pendant l'exécution.
Le #include indique au compilateur qu'il doit inclure du code provenant des fichiers référencés. Il doit donc charger le fichier lorsqu'il rencontre la référence. Cela prendra une quantité de temps déterminée en fonction de l'emplacement du fichier et de sa taille. Le seul surcoût au moment de l'exécution serait si le compilateur incluait du code qui n'était pas référencé, rendant ainsi l'exécutable plus grand que nécessaire, ce qui augmenterait potentiellement les temps de démarrage.
En règle générale, il n'y a que le préfixe de temps de compilation. L'éditeur de liens ne liera que des parties de la bibliothèque qui sont vraiment utilisé par votre programme. Les mauvais lieurs incluront le code de chargement pour les bibliothèques référencées même quand ils ne sont pas utilisés du tout, donc vous payez un peu au moment du démarrage.
Il ralentit la compilation, bien sûr. Dans le cas général, il peut également entraîner votre fichier .exe à contenir des variables globales ou même des fonctions que vous n'utilisez jamais réellement.
Pour les en-têtes C-runtime standard, je ne connais aucun coût d'exécution significatif. Pour les autres en-têtes, vous devez faire attention. Certains en-têtes Windows déclarent des centaines d'UUID qui peuvent finir par gonfler votre exe. La façon de savoir si cela vous coûte quelque chose au moment de l'exécution est de regarder le fichier .map généré par le lieur. Y a-t-il des variables ou des fonctions auxquelles vous ne vous attendiez pas?
Je doute que n'importe quel éditeur de liens moderne inclura des noms globaux que vous n'utilisez jamais. –
@Chris - J'aimerais que ce soit vrai. Mais 'utilisé' signifie quelque chose de différent pour les gens que pour les linkers. les linkers ne peuvent pas vraiment faire la différence entre ça et 'référencé'. il est trivial pour les fichiers d'en-tête d'avoir des références que vous n'utilisez pas vraiment mettez 'extern int _foobar;' dans un en-tête et voyez ce qui se passe. –
Parfois compliqué inclut rendre le temps de compilation gravement mauvais. – sevity
@sevity - C'est généralement en C++, où inclus peut avoir beaucoup de code et de modèles et de trucs poilus. C inclut de façon réaliste ne devient tellement complexe, et en particulier les en-têtes standard comme «» ne seront pas inutilement inefficaces. –