2911 votes

Pourquoi le "using namespace std;" considéré comme une mauvaise pratique?

J'ai été dit par d'autres, à de nombreuses reprises que mon professeur avait tort en disant que nous devrions utiliser using namespace std; dans nos programmes. Par conséquent, nous devrions utiliser std::cout et std::cin et ce sont les plus appropriés. Cependant, ils n'ont même pas claire jamais pourquoi c'est une mauvaise pratique.

Pourquoi est - using namespace std; considéré comme mauvais? Est-il vraiment beaucoup plus efficace, ou risque de déclarer ambigu vars(variables qui partagent le même nom qu'une fonction dans l'espace de noms std)? Ou est-ce l'impact du programme de performances sensiblement que vous obtenez dans l'écriture des applications plus importantes?

2474voto

Greg Hewgill Points 356191

Ce n'est pas lié à la performance à tous. Mais pensez à ceci: Vous êtes à l'aide de deux bibliothèques appelé Foo et Bar:

using namespace foo;
using namespace bar;

Tout fonctionne bien, vous pouvez appeler Blah() de Foo et Quux() à partir de la Barre sans problèmes. Mais un jour, la mise à niveau vers une nouvelle version de Foo 2.0, qui offre maintenant une fonction appelée Quux(). Maintenant que vous avez eu un conflit: les Deux Foo 2.0 et d'un Bar à l'importation Quux() dans votre espace de noms global. Cela va prendre un certain effort pour corriger, surtout si les paramètres de la fonction arriver à égaler.

Si vous avez utilisé foo::Blah() et bar::Quux() puis l'introduction de l' foo::Quux() aurait été un non-événement.

1498voto

sbi Points 100828

Je suis d'accord avec tout ce que Greg a écrit, mais je tiens à ajouter: Il peut même être pire que Greg a dit!!!

Bibliothèque Foo 2.0 pourrait introduire une fonction Quux() c'est un sans ambiguïté meilleur match pour certains de vos appels à l' Quux() de la bar::Quux() votre code appelé pendant des années. Ensuite, ton code compile, mais silencieusement appelle la mauvaise fonction et dieu-sait-quoi. C'est à peu près aussi mauvais que les choses peuvent devenir.

Gardez à l'esprit que l' std de l'espace de noms a des tonnes d'identifiants, dont beaucoup sont très répandues (pensez - list, sort, string, iterator etc.) qui sont très susceptibles à apparaître dans d'autres, trop.

Si vous considérez que c'est peu probable: Il y a une question posée ici sur ALORS, où à peu près exactement ce qui s'est passé (mauvaise fonction appelée en raison omis std:: préfixe) sur la moitié d'une année après que j'ai donné cette réponse. Ici est un autre, plus récent exemple d'une telle question.
Donc, c'est un vrai problème.


Voici encore un point de données: de Nombreuses années, je l'ai aussi utilisé pour le trouver ennuyeux d'avoir à préfixe de tout, de la bibliothèque standard avec std::. Ensuite, j'ai travaillé dans un projet où il a été décidé dès le début que les deux using directives et déclarations sont interdits, sauf pour les fonctions étendues. Devinez quoi? Il a fallu la plupart d'entre nous très peu de semaines pour utilisé pour écrire le préfixe et après quelques semaines de plus, la plupart d'entre nous ont même convenu qu'il fait réellement le code plus lisible. (Il y a une raison à cela: Si vous aimez plus ou moins longue prose est subjective, mais les préfixes objectivement ajouter de la clarté du code. Non seulement le compilateur, mais vous aussi, il est plus facile de voir ce qui identificateur est visé.)

En une décennie, le projet a grandi à plusieurs millions de lignes de code. Depuis ces discussions viennent encore et encore, une fois, j'ai été curieux de voir comment souvent l' (permis) de la fonction de champ using a effectivement été utilisé dans le projet. Je grep avais les sources pour elle et n'a trouvé qu'une ou deux douzaines d'endroits où il a été utilisé. Pour moi, cela indique que, une fois essayé, les développeurs n'ont pas trouver d' std:: assez pénible à employer à l'aide de directives, même une fois tous les 100kLoC même où il a été autorisé à être utilisé.


Bottom line: Explicitement la préfixation de tout ce qui ne fait pas de mal, prend très peu s'y habituer, et a pour objectif d'avantages. En particulier, elle rend le code plus facile à interpréter par le compilateur et par les lecteurs - et qui devrait sans doute être l'objectif principal lors de l'écriture de code.

481voto

ChrisW Points 37322

Je pense que c'est dommage de le mettre dans les fichiers d'en-tête de vos classes: car alors vous seriez obliger toute personne qui veut utiliser vos classes (y compris les fichiers d'en-tête) "à l'aide" (voir tout) d'autres espaces de noms.

Cependant, vous pouvez vous sentir libre de mettre une instruction d'utilisation de votre (privé) *.fichiers cpp.

248voto

David Thornley Points 39051

J'ai récemment rencontré une plainte au sujet de VS 2010. Il s'est avéré que presque tous les fichiers source a ces deux lignes:

using namespace std;
using namespace boost;

Beaucoup de Boost fonctionnalités vont dans le C++0x standard, et VS2010 a beaucoup de C++0x fonctionnalités, donc du coup ces programmes n'ont pas la compilation.

Par conséquent, en évitant using namespace X; est une forme de l'épreuve de l'avenir, un moyen de s'assurer un changement dans les bibliothèques et/ou les fichiers d'en-tête en cours d'utilisation ne va pas casser un programme.

133voto

robson3.14 Points 1237

On ne devrait pas utiliser l'aide de la directive au niveau global, en particulier dans les en-têtes. Cependant, il existe des situations où il est approprié, même dans un fichier d'en-tête:

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; //no problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

C'est mieux que la qualification explicite (std::sin, std::cos...) parce que c'est plus court et a la capacité de travailler avec défini par l'utilisateur à virgule flottante types (via Argument Dépendante de la Recherche).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X