[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:: )
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Utilisation de using namespace
[3DArchi, suite de la séparation de cette discussion]
en haut tu mets :
using namespace std ;
Hou lààà... je me méfie de ce genre de conseil à l'emporte pièce...Envoyé par razily
en haut tu mets :
using namespace std ;
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 ;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
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
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::
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 yeuxTon prof t'as dit une bêtise. std:: n'use ni ton clavier ni tes bouts de doigtset 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...c'est pas çà , mais le fait de lire les codes remplis de std:: alourdit les yeux
est un risque
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
Oui, enfin, tout dépend de la destination de ton projet...
Si c'est un projet perso, ca va, si c'est un projet "d'entreprise", c'est déjà moins évident (en plus, on est souvent confronté au besoin d'accent en franàais:p)
Mais si c'est un projet destiné à avoir une portée plus ou moins internationnale (même si ce n'est qu'un contributeur étranger non francophone), cela devient tout à fait limite...
L'abus nuit, de toutes façons, en tout...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).
Mais, sans aller jusqu'à définir un espace de noms qui ne contiennent qu'une classe, le fait d'avoir au minimum un espace de noms pour le projet et un espace pour chaque partie aspect du projet me semble le minimum requis
Et encore, à condition que tu maitrise parfaitement l'ensemble des fichiers qui sont inclus dans le cpp...Même dans de gros projets, les using dans les cpp, ce n'est pas trop dangereux.
Si, pour les besoins de la cause, tu en viens à inclure des fichiers émanant de deux bibliothèques tierces, tu augemente singulièrement les risques d'ambigüité
J'irais beaucoup plus loin que toi: il ne faut pas seulement faire très attention, mais il faut carrément les exclureLà 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.
Et pas uniquement pour les en-tête destinées à être utilisés dans plusieurs projets, mais bien pour tout fichier d'en-tête
Je déteste les variables en français tout simplement car ce n'est pas du français mais du franglais (pas d'accents etc). Mais ça reste une question de gout.
Quand aux namespaces : la solution aux namespaces ridiculement long c'est les alias de namespace... c'est amha la solution la plus intéressante.
Salut,
C'est clair qu'il faut toujours adapter les règles au contexte d'un projet réel. Cependant, j'ai tendance à penser que std:: ou boost:: et d'une façon générale les namespaces des bibliothèques tierces sont utiles à plus d'un titre : non seulement pour leur objectif premier de trier le bon grain de l'ivraie; mais les namespace permettent aussi de savoir d'où vient une classe ou une fonction. Quand un nouvel entrant arrive sur un projet ou qu'on le reprend bien longtemps après ou tout simplement parce que ma mémoire est limitée
Voilà pourquoi je ne fais quasiment plus de using namespace dans les .cpp sur std ou boost.
Pour les variables en français, je suis de ceux qui acceptent très bien d'écrire sans accents et avec des fôtes sans trop de remords de conscience. C'est pas plus ridicule que d'écrire avec un sabir d'anglais rapidement incompréhensible, surtout, lorsque comme moi, on ne lit pas Byron dans le texte. Dans un contexte pro, j'ai été confronté aux 2 règles : tout en français (en général les grosses boîtes françaises avec contrats publics) et d'autres tout en anglais (plutôt dans les PME françaises ou des boîtes d'origine étrangère).
Entre un français sans accent et un anglais approximatif (ou mal compris par la moitié de l'équipe) je ne sais que choisir... Pour moi, le nom d'une variable ou d'une fonction n'est qu'une convention. Il ne faut pas trop la prendre au sérieux, mais si elle présente l'avantage d'éviter des conflits de noms potentiels, elle est bénéfique.
Sur les noms longs, je pense qu'il y a avant tout un aspect générationnel... Un de mes amis dit qu'on reconnait du code écrit par un moins de 30 ans par le fait qu'aucun nom de variable ne fait moins de 8 lettres... Je ne crois pas qu'une variable d'indice appelée indiceDesLignes est meilleure ou moins bonne qu'un i (que tout matheux reconnait instantanément comme un indice de ligne dans une matrice), mais j'ai remarqué que je n'aime pas trop lire du code avec des noms bavards, et que certains détestent mon code avec des noms courts... Sur une équipe, il faut trouver des conventions. En général, le bon principe est de s'adapter au code existant, et de faire du "à la manière du" programmeur principal. Je remarque que les informaticiens un peu anciens font cela naturellement (leur style d'écriture change en fonction des projets).
Je crois que c'est pareil pour les namespace. Il y a des cas évidents ou il en faut, et d'autres, plus limites, ou cela fait partie des conventions propre à une équipe projet. Dans ce second cas, leur rôle est avant tout d'améliorer la lisibilité en rendant le code plus homogène. Ca rejoint ce que dit 3DArchi. Si on met des std:: devant les fonctions de librairies, pour indiquer leur origine, alors il faut le faire pour toutes, sinon c'est déstabilisant. Si on ne les met pas, on ne les met nulle part, et tout le monde est au courant.
Francois
Sauf que l'intérêt du namespace ne s'arrête pas qu'a la lisibilité. Je pense notamment au koenigs lookup.
Quant aux variables, c'est peut être parce que je fais de la PF mais j'aime aussi les noms cours
Le Koenig Lookup, c'est quand tu utilises déjà des namespaces, en évitant d'avoir à mettre std:: partout, non? J'ai l'impression que c'est ce qui rend les namespaces utilisables en pratique. Sinon, il faudrait probablement renommer le C++ moderne en lang::std::modern::c++...
Francois
Un plus de 30 (40?) ans a été confronté au - une fois à un compilo (C en général) qui avait considéré deux variables différentes comme identiques car le nom avait été silencieusement tronqué à 8 (?) caractères
Globalement, je tend à partager ton avis : se plier à l'existant, tout en le nuançant : essayer quand même de faire évoluer vers du plus 'moderne' (quand cela a un intérêt bien sûr).
Il est vrai que i pour indice, on a rarement fait mieux. A part peut être j ou k
Schématiquement ça consiste à injecter l'espace de nom des arguments pour rechercher les fonctions qui pourraient s'appliquer et qui sont appelées sans l'espace de nom. Exemple typique, l'opérateur << pour les flux défini libre et dans l'espace de nom std. Sans le Koenig lookup (ou argument dependent lookup), l'écriture std::cout<<"coucou" échouerait à la compilation.
Il y a tout un ensemble de noms d'une lettre qui sont utiles. Outre les index i, j, k, on a aussi les base de temps avec t (généralement un flottant), les (pointeurs sur des) objets génériques avec o, les instances d'une classe mesh ou model3d avec m, des vecteurs u,v, des coordonnées x,y,z, etc. Utilisé de manière cohérente tout au long d'un programme, une variable dont le nom ne fait qu'un caractère peut être aisément identifiée.Un plus de 30 (40?) ans a été confronté au - une fois à un compilo (C en général) qui avait considéré deux variables différentes comme identiques car le nom avait été silencieusement tronqué à 8 (?) caractères
Globalement, je tend à partager ton avis : se plier à l'existant, tout en le nuançant : essayer quand même de faire évoluer vers du plus 'moderne' (quand cela a un intérêt bien sûr).
Il est vrai que i pour indice, on a rarement fait mieux. A part peut être j ou k
Comme quoi, savoir se limiter a un seul caractère peut aussi avoir un intérêt
En fait, je trouve que les noms d'une ou deux lettres ont un avantage : ils disent au programmeur qu'il s'agit de variables instrumentales, propres au calcul en cours, comme en maths l'x d'une équation, ou le i d'une somme.
C'est utile parce que dans un algorithme compliqué, savoir ce qui est important et ce qui ne l'est pas, c'est le début de la sagesse...
Sur le nommage, j'observe qu'on nomme souvent ces variables pour qu'elles indiquent leur type : les doubles sont souvent d les flottants f, les entiers i,j,k, les caractères c et ainsi de suite. Mais il y a aussi des habitudes qui viennent des maths (x,y,z pour les coordonnées, n ou p pour des totaux, i,j,k pour des compteurs de boucle).
Personnellement, je pense aimer ces noms courts et abstraits pour deux raisons
1- ca fait du code plus compact, on a plus de chose sur une page d'écran, on voit mieux la structure (je déteste le code aéré avec des retours à la ligne partout et des blancs entre chaque opérateur, quand j'en lis, j'ai toujours l'impression que son auteur me prend pour un idiot, et me parle lentement pour être sur que je comprenne)
2-en éliminant ce qui est du ressort du "commentaire de programmeur" (le fait d'appeler un compteur compteur, ou un pointeur pointeur, ce qui ne sert juste à rien), ca oblige à se concentrer sur le code, et ce qu'il fait. Plus ca va, plus je pense que 10 lignes de code difficile et dense sont bien plus faciles à lire que 100 de code bavard mais simple... D'ailleurs, ces temps ci, j'apprends l'APL et le J, et quand on compare, le C++ ce fait un peu triste, après...
Francois
Je trouve également d'adapter son code au "public" (comprenez : à celui qui devra le lire et le comprendre) de celui-ci...
Sur un forum, lorsqu'il s'agit d'expliquer un modèle quelconque, cela ne me dérange absolument pas d'expliciter clairement ce que peut faire une fonction en la nommant fonctionQuiFaitMachinChose si j'ai le sentiment que cela aidera à la compréhension par un débutant
Ce qui ne veut absolument pas dire que j'utiliserais ce nom de fonction dans un code de production...
En effet, nommer "par convention" une variable i, x, y, ptr, ref ou quoi que ce soit d'autre ne me dérange absolument pas une fois sorti du contexte "didactique" pour autant que l'on puisse partir du principe que la convention est connue et globalement suivie
juste une remarque , Pourquoi sur Eclipse (Galileo) ; dès qu'on crée un projt C++
il met automatiquement using namespace std
c'est pour dire que c'est pas dangeureux , au contraire çà faciliterait les choses et c'est pratique
Il le met parce que pour un *petit* projet, où tu travailles seul, et ou les conflits de noms sont rares, ça permet d'avoir des programmes qui "compilent tout de suite" (sans avoir à se rendre compte que cout, c'est std::cout).juste une remarque , Pourquoi sur Eclipse (Galileo) ; dès qu'on crée un projt C++
il met automatiquement using namespace std
c'est pour dire que c'est pas dangeureux , au contraire çà faciliterait les choses et c'est pratique
En fait, Galileo te propose par défaut un projet "sans namespace", et je te parie que la directive using, il la met dans le cpp, et pas dans l'entête...
Maintenant, il est utile de savoir que les namespaces existent et à quoi ils servent. Ce qu'on dit, c'est que sur de gros projets, ca devient souvent nécessaire.
Francois
Ce n'est pas une "astuce" d'utiliser le using namespace sinon il n'existerait pas.
C'est vrai que pour les débutants c'est pas facile de commencer en expliquant ce qu'est un namespace, alors on met using namespace std; avant le main et hop c'est bon.
Mais dans un vrai projet, connaissant le langage, je préfère laisser std:: ou boost:: (ou autre) devant les objects/fonctions pour bien montrer qui appartient à quoi.
Et si j'utilise des namespaces pour mes préfèrences persos (genre pour du boost lambda), jamais je ne le mets de manière "globale", mais dans la fonction/méthode
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager