Discussion :

[BigNic]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
using namespace std
vector<int> myVector;

plutot que faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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é...

[bigquick]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

using std::cout;

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

[amaury pouly]

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

[Jean-Marc.Bourguet]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Jean-Marc.Bourguet]

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.

[Blowih]

Salut,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[swirtel]

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.

[Jan Rendek]

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

[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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[bigquick]

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.

[swirtel]

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.

[Jan Rendek]

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

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.