l’inclusion de l’espace de nommage augmente la taille de l’exe

J’ai assisté à une session au cours de laquelle il était enseigné que nous ne devrions pas utiliser “namespace std”, mais plutôt “std :: cout” pour utiliser un appel de l’espace de noms std car cela augmenterait la taille du fichier binary.

J’ai essayé de vérifier la même chose avec l’expérience suivante. Le code et sa sortie est comme suit: –

[Fooo@EXP]$ cat namespacestd.cpp #include #ifdef STD using namespace std; #endif int main() { #ifndef STD std::cout< Workign \n"; #else cout< Workign \n"; #endif return 0; } [Fooo@EXP]$ time g++ -c namespacestd.cpp -DSTD real 0m0.246s user 0m0.215s sys 0m0.030s [Fooo@EXP]$ size namespacestd.o text data bss dec hex filename 310 8 1 319 13f namespacestd.o [Fooo@EXP]$ time g++ -c namespacestd.cpp real 0m0.258s user 0m0.224s sys 0m0.034s [Fooo@EXP]$ size namespacestd.o text data bss dec hex filename 310 8 1 319 13f namespacestd.o [Fooo@EXP]$ time g++ -o namespacestd namespacestd.cpp -DSTD real 0m0.293s user 0m0.251s sys 0m0.042s [Fooo@EXP]$ size namespacestd text data bss dec hex filename 1980 580 288 2848 b20 namespacestd [Fooo@EXP]$ time g++ -o namespacestd namespacestd.cpp real 0m0.274s user 0m0.239s sys 0m0.035s [Fooo@EXP]$ size namespacestd text data bss dec hex filename 1980 580 288 2848 b20 namespacestd [Fooo@EXP]$

Comme je vois de mon expérience que

il n’y a pas d’effet sur la taille du binary

seulement

il y a une différence dans le temps de compilation .

Veuillez me corriger si mes conclusions sont erronées

Merci

L’utilisation de namespace std ne devrait pas affecter la taille binary de la plupart des compilateurs. Cela devrait encore être évité pour une autre raison:

L’espace de noms std est vraiment gros. Il y a littéralement des milliers d’identifiants qui sont tous dans la scope de votre programme. Cela augmente la probabilité de collision avec vos propres identifiants ou identifiants provenant d’autres bibliothèques, ce qui peut provoquer de mauvaises sursockets.

Voir aussi cette question connexe: Pourquoi “using namespace std” est-il considéré comme une mauvaise pratique?

Les fichiers binarys ne sont pas les mêmes, car dans un fichier, vous avez défini STD et dans l’autre, vous ne l’avez pas. J’ai aussi différentes tailles.

Cependant, si vous supprimez des symboles, vous obtiendrez des fichiers binarys presque identiques (ce qui est différent, ce sont des parameters d’en-tête ELF, comme le temps de compilation).

Si vous changez votre exemple à ceci:

 #include using namespace std; int main() { #if 0 std::cout<<"\n ==> Workign \n"; #else cout<<"\n ==> Workign \n"; #endif return 0; }

et ensuite comstackr avec #if 1 et #if 0 , vous allez avoir des binarys de même taille, même sans les symboles de segmentation.

La différence de temps de compilation est normale. Lorsque la macro est définie, le fichier est plus volumineux et le préprocesseur doit en faire plus. Cependant, les nouveaux PC sont si puissants que j’ignorerais simplement cette augmentation de temps.

il n’y a pas d’effet sur la taille du binary

Il ne devrait y avoir aucune différence entre le code exécutable et les données, car dans les deux cas, vous faites la même chose avec le même object et le processus de recherche pour trouver cet object depuis son nom se produit pendant la compilation. Toutefois, il est possible que dans certaines circonstances, ils génèrent des quantités de métadonnées différentes, telles que des informations de débogage.

il y a une différence dans le temps de compilation

Toute modification apscope à la source pourrait modifier le temps de compilation, mais vous n’avez pas présenté suffisamment de données pour déterminer si la différence est statistiquement significative. Vous devez répéter l’expérience plusieurs fois pour chaque configuration, calculer la moyenne et la variance des deux échantillons et appliquer un test de signification à la différence de moyennes.

Quoi qu’il en soit, même si vous déterminez que la pollution de l’espace de noms global accélère considérablement la compilation, tout gain de temps sera minime comparé au temps potentiellement perdu lors du suivi des collisions de noms. Il y a beaucoup de noms dans l’espace de noms std , dont vous voudrez peut-être utiliser plusieurs dans votre propre code. C’est la raison pour laquelle on évite la pollution des espaces de noms. quiconque prétend que cela affectera la taille du fichier binary ne comprend pas bien ce dont il parle.

J’ai assisté à une session au cours de laquelle il était enseigné que nous ne devrions pas utiliser “namespace std”, mais plutôt “std :: cout” pour utiliser un appel de l’espace de noms std car cela augmenterait la taille du binary.

Très bon conseil, logique absurde. Ce raisonnement est une optimisation prématurée, et il est faux de démarrer.

Ne jamais utiliser en using namespace std; dans un fichier d’en-tête. Cette directive dans un fichier d’en-tête pollue l’espace de noms global avec des éléments de l’espace de noms std dans chaque fichier qui inclut votre fichier d’en-tête.

Même dans un fichier source, beaucoup préfèrent std::whatever car cela rend le code plus lisible, plus compréhensible et moins sujet aux erreurs. Au prix unique de quelques caractères de frappe, ce std:: prefix communique pour toujours l’intention du compilateur, et plus important encore, le lecteur humain / responsable humain du code. Il ne fait aucun doute que le code appelle quelque chose de la bibliothèque standard.

La seule justification pour employer un using namespace ; La directive est une pure paresse sur le programmeur pour sauver quelques caractères de frappe. Ces quelques caractères enregistrés de saisie sont très coûteux.