using namespace std Vs std::

quels les avantages et les incov�nients d'utiliser un

Code:

---

1 2	using namespace std vector<int> myVector;

---

plutot que faire

Code:

---

1 2 3

#include <vector> /* d'autre code*/ std::verctor<int> myVector;

---

en fait dans ma boite une r�gle de dev nous oblige � utiliser la solution std:: mias je ne comprend pas bien pourquoi.

Std est l'espace de nommage standard.

d'autres objets vector peuvent etre cr�es dans d'autres espacs de nommage (xxx par exemple) et cohabiter avec celui-ci grace aux std:: et xxx::

Si tu utilises unsing namespace tu t'interdis cette posibilit�...

Donc entres autres, puisque tes headers peuvent �tre inclus par tout le monde, ce n'est vraiment pas conseill� d'utiliser

Code:

---

using namespace std; // ou n'importe quel autre

---

dedans.

Par contre dans tes .cpp, le probl�me ne regarde que toi :)
Le "using" peut te simplifier le code, mais tu seras parfois oblig� de t'en passer si il y a des conflits. Sinon dans ces cas l� tu pourras toujours utiliser

Code:

---

using std::cout;

---

par exemple, pour ne pas utiliser le namespace en entier, mais seulement ce qui t'int�resse et ne "conflicte" pas :)

personnellement j'ai eut des probl�me avec using namepsace std � cause des conflits et donc depuis j'utilise syst�matiquement std:: . �� co�te rien mais �� �vite les probl�mes

Il y a deux cas: dans les ent�tes et en dehors des ent�tes (et apr�s tous ceux-ci).

Dans les ent�tes c'est g�n�ralement une tr�s mauvaise id�e de faire un using namespace, ou m�me des using std::nom. Le r�sultat est que tout ceux qui incluent cet ent�te directement ou non se retrouve avec ces noms import�s dans le namespace global et �a peut poser des conflits. Cas v�cu: un ent�te inclus indirectement faisait un using namespace std, un autre d�finissait un type list global, un troisi�me incluait <list> r�sultat mon code ne compilait alors que je n'�tais client direct que de deux de ces ent�tes, je n'�tait que client indirect du troisi�me...

Dans le corps, il y a aussi des risques de conflits, mais au moins le probl�me appara�t dans le code de celui qui a d�cid� de faire un using, pas de quelqu'un qui n'a m�me pas id�e qu'un using est fait. Cela ne veux pas dire qu'une modification dans un fichier qu'on ne ma�trise pas ne va pas entra�ner indirectement une erreur dans le tient. Ce fichier pouvant �tre l'impl�mentation de la biblioth�que standard (puisqu'en C++ tout ent�te standard peut inclure n'importe quel autre).

Il est cependant des cas o� l'utilisation de using est bien agr�able, parfois quasiment obligatoire, parce que �a permet d'utiliser la recherche des noms non qualifi�s. Mais dans ces cas, on peut restreindre la port�e de using � un bloc. On peut �crire ainsi:

Code:

---

1 2 3 4 5 6

template <typename T>void maFonction(T& a, T& b) { ... using std::swap; swap(a, b); ... }

---

et on utilisera soit std::swap, soit un swap pour le type param�tre du template d�fini dans le namespace global ou dans le namespace o� se trouve d�finit ce type s'il y en a un.

Citation:

---

Envoy� par Gandalf

Std est l'espace de nommage standard.

d'autres objets vector peuvent etre cr�es dans d'autres espacs de nommage (xxx par exemple) et cohabiter avec celui-ci grace aux std:: et xxx::

Si tu utilises unsing namespace tu t'interdis cette posibilit�...

---

On peut souvent r�soudre les ambiguit�s en qualifiant les noms...

Note que personnellement, je n'utilise pas using namespace, il y a un peu trop de noms d�finis dans la biblioth�que standard.

Salut,

Citation:

---

Donc entres autres, puisque tes headers peuvent �tre inclus par tout le monde, ce n'est vraiment pas conseill� d'utiliser

Code:

---

using namespace std; // ou n'importe quel autre

---

---

+1

delpus si tu travaille avec VisualC++ 6, il appreci moyen le "using namespace", quelque fois j'ai rencontr� des erreurs du type "Internal Error" a cause du using namespace.

Ciao

Comme le dit Jean-Marc.Bourguet, il vaut mieux sp�cifier la classe et son namespace.
Cela simplifie largement la compr�hension du code.
1) pas de conflit
2) pas de probl�mes pour savoir de quel namespace provient ta classe
3) propret� du code.

Citation:

---

Envoy� par swirtel

Comme le dit Jean-Marc.Bourguet, il vaut mieux sp�cifier la classe et son namespace.

---

J'ai beau relire JMB, je ne suis pas d'accord avec l'interpr�tation que tu fais de ses propos.
D'ailleurs en le paraphrasant, moi aussi je suis d'accord avec lui.
L'utilisation d'une directive "using namespace XXX" dans un fichier d'ent�te est � bannir.
Maintenant dans un fichier source c'est g�n�ralement pas une source de probl�me. Notamment si le namespace en question est le namespace standard.
Clairement, si j'utilise des fonctions ou des structures qui pourraient entrer en conflit avec un nom de la biblioth�que standard, j'aurais tendance � le qualifier compl�tement pour �viter les confusions, ou bien utiliser un typedef si c'est un nom � ralonge.

Maintenant, la premi�re des r�gles, c'est que lorsque l'on fait partie d'un projet qui fixe des 'coding standards', on les suit � la lettre :D

Si ton "code guide" contient une erreur de ce style, cela ne vaut m�me pas l'int�r�t de te lancer dans ce style de projet.

L'utilisation du namespace permet d'�tre certain de la classe que tu utilises.

imagine que tu red�finisses simplement 'cout' comme �tant une instance d'une classe "Ne_fait_rien" et que tu surcharges l'op�rateur << pour cette classe.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

namespace Exemple { class Ne_fait_rien { };   Ne_fait_rien cout; }   using namespace std; using namespace Exemple;   cout << "Alors qui bosse ici ?" << std::endl;

---

--> il est obligatoire d'employer le namespace comme pr�fix. C'est plus safe et plus claire pour tout d�veloppeur qui relira le code.

Dans ce cas l� �videmment.
Mais c'est chercher que de d�finir une variable "cout", surtout membre d'une classe avec un operateur << :)

Tu prends le cas extreme ici, mais il y a � des cas ou tu es bien content d'utiliser using namespace, par exemple si tu utilise tr�s souvent un ensemble de classes provenant du m�me namespace. Il arrive que les namespaces soient l� pour regrouper des classes fonctionnellement proches, m�me si � priori aucune ambiguit� flagrante pourrait se pr�senter. Dans ce cas l� je ne vois pas ce qui emp�che de r�soudre le namespace d�s le haut du fichier CPP.

Comme tu veux, mais je pr�f�re proc�der de cette mani�re.

En plus, cela sera plus facile si tu dois faire des replaces dans ton code de mani�re automatique.

Citation:

---

Envoy� par swirtel

Si ton "code guide" contient une erreur de ce style, cela ne vaut m�me pas l'int�r�t de te lancer dans ce style de projet.

---

Merci de corriger mon 'coding standard' erron�, cependant mon projet se porte bien et comprend maintenant pas loin de 50 000 lignes de code et perdure depuis plus de 5 ans (www.qgar.org). Tu ne m'en voudras donc pas de persister et de signer en plus.

L'erreur que tu donnes n'en est pas une, car dans ce cas tu as une ambiguit� de nommage et le compilateur te fournira une erreur. Ce sera charge au programmeur de lever cette ambiguit�. Maintenant, je travaille rarement avec des personnes qui utilisent 'cout' comme nom de variable, bien qu'une ambiguit� bien souvent source d'erreur soit std::min et std::max.
Le vrai risque d'une directive 'using' globale dans un source est si celui-ci est modifi� pour utiliser un composant non pr�vu au d�part (une nouvelle biblioth�que par exemple) dont certains �l�ments pourraient provoquer un conflit de nommage avec ceux d'un namespace existant. Or quand tu d�finis l'impl�mentation d'une classe les d�pendances en termes de composants sont g�n�ralement fix�es. Donc ce cas est tr�s rare.
De plus, si tu souhaites vraiment l'�viter, il suffit de qualifier compl�tement tous les noms de ce nouveau module uniquement.
Ce que tu as � gagner � utiliser une directive globale est g�n�ralement un code plus lisible, donc plus facilement extensible et maintenable.

Libre � toi bien s�r d'utiliser les conventions que tu souhaites si tu en est ma�tre. Mais si tu veux critiquer les m�thodes d'autrui, fait le plut�t avec de vrais exemples et de vrais arguments. Prends aussi le soin de lire les intervenants jusque au bout

Citation:

---

Envoy� par VoidSeer

Clairement, si j'utilise des fonctions ou des structures qui pourraient entrer en conflit avec un nom de la biblioth�que standard, j'aurais tendance � le qualifier compl�tement pour �viter les confusions, ou bien utiliser un typedef si c'est un nom � rallonge.

---