Pourquoi "using namespace std ;" est-il considéré comme une mauvaise pratique ?

Question

D'autres m'ont dit qu'écrire using namespace std; dans le code est erronée, et que je devrais utiliser std::cout y std::cin directement à la place.

Pourquoi est-ce que using namespace std; est-elle considérée comme une mauvaise pratique ? Est-elle inefficace ou risque-t-elle de déclarer des variables ambiguës (des variables qui partagent le même nom qu'une fonction en std espace de noms) ? Cela a-t-il un impact sur les performances ?

Answer 1

Cela n'est pas du tout lié aux performances. Mais considérez ceci : vous utilisez deux bibliothèques appelées Foo et Bar :

using namespace foo;
using namespace bar;

Tout fonctionne bien, et vous pouvez appeler Blah() de Foo et Quux() de Bar sans problèmes. Mais un jour, vous passez à une nouvelle version de Foo 2.0, qui offre maintenant une fonction appelée Quux() . Maintenant, il y a un conflit : Foo 2.0 et Bar importent tous deux Quux() dans votre espace de nom global. Cela va demander un certain effort pour le corriger, surtout si les paramètres de la fonction correspondent.

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

Answer 2

Je suis d'accord avec tout. Greg a écrit mais j'aimerais ajouter : Ça peut même être pire que ce que Greg a dit !

La bibliothèque Foo 2.0 pourrait introduire une fonction, Quux() qui correspond mieux, sans ambiguïté, à certains de vos appels à Quux() que le bar::Quux() votre code a été appelé pendant des années. Puis votre le code compile toujours mais il appelle silencieusement la mauvaise fonction et fait Dieu sait quoi. C'est à peu près aussi mauvais que les choses peuvent devenir.

N'oubliez pas que le std possède des tonnes d'identifiants, dont beaucoup sont des muy communs (pensez list , sort , string , iterator ) qui sont très susceptibles d'apparaître dans d'autres codes également.

Si vous considérez que c'est peu probable : Il y avait une question posée ici, sur Stack Overflow, où il s'est passé à peu près exactement la même chose (mauvaise fonction appelée en raison d'une omission std:: préfixe) environ une demi-année après avoir donné cette réponse. Ici est un autre exemple, plus récent, d'une telle question. Il s'agit donc d'un véritable problème.

---

Voici un autre point de données : Il y a de très nombreuses années, je trouvais également ennuyeux de devoir préfixer tout ce qui provenait de la bibliothèque standard par le terme std:: . J'ai ensuite travaillé sur un projet où il avait été décidé dès le départ que les deux using Les directives et les déclarations sont interdites, sauf pour la portée des fonctions. Devinez quoi ? Il n'a fallu que quelques semaines à la plupart d'entre nous pour s'habituer à écrire le préfixe, et après quelques semaines supplémentaires, la plupart d'entre nous étaient même d'accord sur le fait que cela rendait le code plus lisible . Il y a une raison à cela : Que vous aimiez une prose plus courte ou plus longue est subjectif, mais les préfixes ajoutent objectivement de la clarté au code. Non seulement le compilateur, mais vous aussi, trouvez plus facile de voir à quel identifiant il est fait référence.

En une décennie, ce projet a atteint plusieurs millions de lignes de code. Comme ces discussions reviennent sans cesse, j'ai été un jour curieux de savoir combien de fois le champ d'application de la fonction (autorisé) using a été utilisé dans le projet. J'ai parcouru les sources pour le trouver et je n'ai trouvé qu'une ou deux douzaines d'endroits où il était utilisé. Pour moi, cela indique que, une fois essayé, les développeurs ne trouvent pas std:: assez douloureux pour employer des directives d'utilisation même une fois tous les 100 kLoC, même lorsque son utilisation était autorisée.

---

La ligne du bas : Préfixer tout explicitement ne fait pas de mal, demande très peu d'habitude et présente des avantages objectifs. En particulier, cela rend le code plus facile à interpréter par le compilateur et par les lecteurs humains - et cela devrait probablement être l'objectif principal quand on écrit du code.

Answer 3

Le problème de mettre using namespace dans les fichiers d'en-tête de vos classes, c'est que cela oblige quiconque veut utiliser vos classes (en incluant vos fichiers d'en-tête) à "utiliser" (c'est-à-dire à voir tout ce qui se trouve dans) ces autres espaces de noms.

Cependant, vous pouvez vous sentir libre de mettre une déclaration using dans vos fichiers *.cpp (privés).

---

Attention, certaines personnes ne sont pas d'accord avec le fait que je dise "sentez-vous libre" comme ça, car bien qu'une using dans un fichier cpp est meilleur que dans un en-tête (parce que cela n'affecte pas les personnes qui incluent votre fichier d'en-tête), ils pensent que ce n'est pas encore bon (car selon le code, cela pourrait rendre l'implémentation de la classe plus difficile à maintenir). Cette entrée C++ Super-FAQ dit,

La directive using existe pour le code C++ hérité et pour faciliter la transition vers les espaces de noms, mais vous ne devriez probablement pas l'utiliser régulièrement, du moins pas dans votre nouveau code C++.

La FAQ suggère deux alternatives :

• Une déclaration d'utilisation :

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";

• Il suffit de taper std: :

  std::cout << "Values:";

Answer 4

Je suis récemment tombé sur une plainte concernant Visual Studio 2010 . Il s'est avéré que presque tous les fichiers sources contenaient ces deux lignes :

using namespace std;
using namespace boost;

Beaucoup de Boost sont intégrées à la norme C++0x, et Visual Studio 2010 comporte de nombreuses fonctionnalités C++0x, de sorte que, soudainement, ces programmes ne compilaient plus.

Par conséquent, il faut éviter using namespace X; est une forme d'anticipation, une façon de s'assurer qu'un changement dans les bibliothèques et/ou les fichiers d'en-tête utilisés ne va pas casser un programme.

Answer 5

On ne devrait pas utiliser le using à l'échelle mondiale, en particulier dans les en-têtes. Cependant, il existe des situations où elle est appropriée 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 ...), car il est plus court et a la capacité de travailler avec des types de virgule flottante définis par l'utilisateur (par l'intermédiaire de recherche en fonction de l'argument (ADL)).