Discussion :

[bogoss91]

Salut à tous.

Je me balladais sur internet, quand je suis tombé sur le code source de la classe std::complex<>, et je me demande pourquoi il y a des _ et des __, à part pour réduire la lisibilité de code?

Merci

[Willy S.]

Salut,
personnellement, je place des "_" devant les noms de variables dans mes classes, pour les distinguer des autres variables.

Exemple pour une fonction quelconque j'écrirais :

Code :

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

1
2
3
void initialiser(int angle) {
_angle = angle; // _angle est celui de la classe et angle la variable envoyée
}

Pour le lien que tu as envoyé, ce doit être des méthodes de programmation mais je sais pas à quoi elles correspondent.

[JolyLoic]

Salut,
personnellement, je place des "_" devant les noms de variables dans mes classes, pour les distinguer des autres variables.

Tu n'as pas le droit de le faire.

Tous les noms qui ont __ n'importe où ou un _ au début sont réservés (les règles sont plus détaillées, mais autant simplifier et ne pas prendre de risque), et l'utilisateur d'un compilateur n'est pas sensé les utiliser.

L'objectif ? Réserver toute une série de noms que la personne qui implémente un compilateur C++ ou sa bibliothèque standard pourra utiliser, sans risque qu'ils entrent en conflit avec un nom défini par l'utilisateur.

Donc, à ne pas respecter cette contrainte du langage, tu t'expose à ce que ton code soit non portable, car entrant en conflit avec la bibliothèque standard d'un autre compilateur.

[Willy S.]

Ah merci de la précision, je vais rectifier cela.
C'est vrai que je me souviens d'avoir lu quelque part d'utiliser les préfixes "m_" dans nos classes (et non "_").
C'est bon ça alors ?

[Alp]

Oui, et tu peux aussi suffixer par "_". Du genre angle_ = angle; ...

[JolyLoic]

Personnellement, je préfère les nommer avec my ou mon, myAngle = angle. Je trouve qu'avoir un nom aisément prononçable facilite la fluidité de lecture, ainsi que les discussions entre collègues autour du code.

[NiamorH]

Si tu regardes chez Loki, il fait angle_, si tu regarde chez boost ils font m_angle...

%C'est à toi de voir, en tout cas surtout pas _angle ni __angle.

[Alp]

Personnellement je trouve le code de Loki très lisible.

[Luc Hermitte]

Et là les spécs qualité décidées en partenariat avec ton client principal demandent de post-fixer les noms des paramètres formels par ... un underscore.
C'est déroutant au début, et puis on s'y fait bien jusqu'à ce que l'on réouvre un code loki/ACE/...

[Freud44]

pour tout ce qui est variable passée en paramètre, j'ai tendance à placer un "val" devant.

par exemple: ObjAdmin = valObjAdmin;

ceci dit, j'ai complètement ommis de discerner mes variable de ma classe de celles de la fonction par exemple...grosse erreur

[valefor]

Citation:
Envoyé par Willy S. Voir le message
Salut,
personnellement, je place des "_" devant les noms de variables dans mes classes, pour les distinguer des autres variables.
Tu n'as pas le droit de le faire.

Hé bien moi je fait comme Willy S. Et je ne vois vraiment pas pourquoi on n'aurait pas le droit.

Effectivement, je suis d'accord que les _ et __ sont utilisés pour les fonctions internes (du système, du compilo ou je ne sais quoi). Mais l'intérieur d'une classe n'est pas censé être visible de ses utilisateurs, et tant bien même qu'on ait à faire à une structure, le scope permet de ne pas rentrer en conflit.

Pour moi, les namespace et les classes sont des moyens de cloisonner notre code et de pouvoir prendre à peu près toutes les libertés de convention de nomage.

[Sylvain Togni]

Hé bien moi je fait comme Willy S. Et je ne vois vraiment pas pourquoi on n'aurait pas le droit.

Effectivement, je suis d'accord que les _ et __ sont utilisés pour les fonctions internes (du système, du compilo ou je ne sais quoi). Mais l'intérieur d'une classe n'est pas censé être visible de ses utilisateurs, et tant bien même qu'on ait à faire à une structure, le scope permet de ne pas rentrer en conflit.

Pour moi, les namespace et les classes sont des moyens de cloisonner notre code et de pouvoir prendre à peu près toutes les libertés de convention de nomage.

Sauf que si une implémentation défini, par exemple, une macro _angle, tu a beau entourer ton identifiant _angle de tous les namespaces que tu veux, il y aura quand même un conflit.

[Kujara]

Sauf que si une implémentation défini, par exemple, une macro _angle, tu a beau entourer ton identifiant _angle de tous les namespaces que tu veux, il y aura quand même un conflit.

C'est pour ça que le standard t'interdit d'utiliser le double underscore, ou l'underscore suivit d'une majuscule.

Donc techniquement tu peux déja utiliser _angle puisque c'est minuscule, mais pas _Angle ...

Code :

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

1
2
3
void initialiser(int angle) {
_angle = angle; // _angle est celui de la classe et angle la variable envoyée
}

C'est mal ^^.

m_nomdubidule c'est mieux .

Enfin, question de gout, bien sur.

Perso j'utilise _function() pour les fonctions privées de mes classes, mais c'est tout.

[befalimpertinent]

Ceux qui préfixes leurs variables d'un "_" confondent peut être avec la pratique courante du C# : préfixer les attributs membres d'un underscore et l'enlever dans la définition de sa property.

En tout cas je rejoins les autres : en C++, pour ces propres classes c'est mal

[valefor]

Sauf que si une implémentation défini, par exemple, une macro _angle, tu a beau entourer ton identifiant _angle de tous les namespaces que tu veux, il y aura quand même un conflit.

Je voulais uniquement parler des attributs des classes.

[Luc Hermitte]

Je voulais uniquement parler des attributs des classes.

Et ?
En quoi une macro sait faire la différence entre une classe et un espace de noms ?

Le seul truc opposable, c'est que seuls _TOTO et __toto sont réservés (_Toto aussi ?).
Après, pour éviter les pièges idiots, on généralise. D'autant que cela permet d'assurer une uniformité, et de lever la tentation d'également nommer de la sorte les classes embarquées, en particulier celles dont le nom est un accronyme.

[valefor]

Je ne comprend vos explications sur les macros.

Par exemple j'ai la classe

Code :

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

1
2
3
4
class Foo
{
unsigned _bar;
}

Où est le risque que _bar soit vu d'où que ce soit ? Vous pouvez me donner un exemple ?

Les sénior qui bossent avec moi m'ont appris à éviter les macros comme la peste, et l'expérience m'a effectivement montré qu'il y a très peu de choses qu'on ne puisse pas coder en C++ sans avoir recours aux macros. Question lisibilité notamment les macros ne sont pas géniales. Puis pour débugger non plus...

[JolyLoic]

Code :

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

1
2
3
4
5
#include<vector>
class Foo
{
unsigned _Bar;
}

Pour peu que dans vector, que tu ne contrôles pas, il y ait la ligne suivante (autorisée par le standard) :

Code :

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

1
2
 
#define _Bar 42

Ton code est cassé.

[Thierry Chappuis]

Je ne comprend vos explications sur les macros.

Par exemple j'ai la classe

Code :

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

1
2
3
4
class Foo
{
unsigned _bar;
}

Où est le risque que _bar soit vu d'où que ce soit ? Vous pouvez me donner un exemple ?

Les sénior qui bossent avec moi m'ont appris à éviter les macros comme la peste, et l'expérience m'a effectivement montré qu'il y a très peu de choses qu'on ne puisse pas coder en C++ sans avoir recours aux macros. Question lisibilité notamment les macros ne sont pas géniales. Puis pour débugger non plus...

Le problème intervient si l'implantation utilise une macro nommé _bar dans un fichier d'en-tête (je sais que _Bar est réservé, qu'en est-il de _bar?)... Dans ce cas, peu importe la portée où est définie ta variable. Tu ne pourras pas l'empêcher, même si on utilise beaucoup moins les macros en C++ qu'en C.

Thierry

[JolyLoic]

(je sais que _Bar est réservé, qu'en est-il de _bar?)...

— Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165)
[...]
3 Each name having two consecutive underscores (2.11) is reserved to the implementation for use as a name with both extern "C" and extern "C++" linkage.