Discussion :

[razily]

[3DArchi, suite de la séparation de cette discussion]
en haut tu mets :
using namespace std ;(et comme çà t'évites d'écrire de temps en temps std:: )

[koala01]

en haut tu mets :
using namespace std ;(et comme çà t'évites d'écrire de temps en temps std:: )

Hou lààà... je me méfie de ce genre de conseil à l'emporte pièce...

Il faut bien comprendre que les espaces de noms ne sont pas uniquement là pour faire joli, mais pour limiter les risques d'ambigüité si deux bibliothèques définissent une classe dont le nom est identique, et permettre ainsi d'éviter aux programmeur d'avoir à préfixer le nom de leurs propres classes.

Le gros problème avec la directive using namespace est qu'elle a la fâcheuse manie de se répandre partout si elle est placée dans un fichier d'en-tête.

Je te rappelle en effet que l'inclusion de fichier est récursive en C++, et donc que si tu met la directive dans un fichier d'en-tête, elle se retrouvera dans tous les fichiers qui incluent le fichier d'en-tête... Y compris dans les fichier qui incluent un fichier qui inclut un fichier qui inclut un fichier (qui... on peut continuer longtemps comme cela ) dans lequel se trouve la directive

Tu risque donc très fort, alors que tu n'aurais eu aucun problème si tu ne l'avais pas mise, de te retrouver avec des ambigüités t'obligeant, malgré tout, à utiliser le nom long (comprend: avec l'espace de noms) si, d'aventure, tu travaille effectivement avec plusieurs bibliothèques.

Il faut donc prendre l'habitude de placer cette directive uniquement dans les fichier d'implémentation dont on est sur qu'il ne seront jamais inclus par ailleurs (ce qui disqualifie donc les fichiers d'implémentation de fonction template).
Et puis, std:: , c'est pas si embêtant que ca à écrire

[razily]

Hou lààà... je me méfie de ce genre de conseil à l'emporte pièce...

Il faut bien comprendre que les espaces de noms ne sont pas uniquement là pour faire joli, mais pour limiter les risques d'ambigüité si deux bibliothèques définissent une classe dont le nom est identique, et permettre ainsi d'éviter aux programmeur d'avoir à préfixer le nom de leurs propres classes.

Le gros problème avec la directive using namespace est qu'elle a la fâcheuse manie de se répandre partout si elle est placée dans un fichier d'en-tête.

Je te rappelle en effet que l'inclusion de fichier est récursive en C++, et donc que si tu met la directive dans un fichier d'en-tête, elle se retrouvera dans tous les fichiers qui incluent le fichier d'en-tête... Y compris dans les fichier qui incluent un fichier qui inclut un fichier qui inclut un fichier (qui... on peut continuer longtemps comme cela ) dans lequel se trouve la directive

Tu risque donc très fort, alors que tu n'aurais eu aucun problème si tu ne l'avais pas mise, de te retrouver avec des ambigüités t'obligeant, malgré tout, à utiliser le nom long (comprend: avec l'espace de noms) si, d'aventure, tu travaille effectivement avec plusieurs bibliothèques.

Il faut donc prendre l'habitude de placer cette directive uniquement dans les fichier d'implémentation dont on est sur qu'il ne seront jamais inclus par ailleurs (ce qui disqualifie donc les fichiers d'implémentation de fonction template).
Et puis, std:: , c'est pas si embêtant que ca à écrire

Pourquoi , je fais seulement çà pour std ;
vu qu'on utlise souvent cout et cin
et c'est un prof à la fac qui nous a appris l'astuce afin d'éviter d'écrire
std::

[3DArchi]

et c'est un prof à la fac qui nous a appris l'astuce afin d'éviter d'écrire

Ton prof t'as dit une bêtise. std:: n'use ni ton clavier ni tes bouts de doigts

[razily]

Ton prof t'as dit une bêtise. std:: n'use ni ton clavier ni tes bouts de doigts

c'est pas çà , mais le fait de lire les codes remplis de std:: alourdit les yeux et je ne vois pas vraiment en quoi le fait d'écrire using namespace std;
est un risque

[Invité]

c'est pas çà , mais le fait de lire les codes remplis de std:: alourdit les yeux et je ne vois pas vraiment en quoi le fait d'écrire using namespace std;
est un risque

Parce que std contient beaucoup de mots courts et "evidents". Par exemple, elle définit des fonctions min et max, des classes list, et vector, et string, etc etc etc...

Comme ce sont des mots très courants, dans un projet un peu large, il y a un risque que quelqu'un définisse sa fonction, ou variable, appelée "min", ou "list", et là, sans namespace, tu peux avoir des bugs étranges si ton programme confond les deux "min", ou les deux "list" (le compilateur en attrape beaucoup, mais ceux qu'il ne chope pas sont très durs à trouver).

Maintenant, les namespaces ne sont pas la seule solution (c'est vrai qu'on arrive vite à des noms ridiculement longs). Une méthode consiste à nommer ses variables EN FRANCAIS. Cela réduit les risques. Une autre à suivre des règle de nommage différentes de la STL (par exemple, éviter les noms tout en minuscule). A l'échelle d'un projet normal (ie pas trop énorme), on peut vivre presque sans namespaces (sachant que des namespace mal gaulés provoquent autant de bugs tout aussi dégoutants, et que l'abus des namespaces provoque souvent une "ossification" prématurée du code).

Même dans de gros projets, les using dans les cpp, ce n'est pas trop dangereux.

Là où il faut faire très attention, c'est quand tu utilises des directives using dans des entêtes destinées à être utilisés dans plusieurs projets, voire diffusés à l'extérieur. Le préprocesseur du C++ est extrèmement bête, et le seul fait d'inclure le .h, parfois de manière indirecte, peut alors créer des conflits de nom.

Francois