intérêt d'écrire _nom de variable

Version imprimable

Bonjour

Quel est l'intérêt de positionner un _ devant une variable comme dans le constructeur suivant

Merci d'avance
Voici le constructeur

Code:

1
2
3
4
5
6
7
8
9
Actif::Actif(int _dimension, double _r, double _sigma, double _pas) {      
                 r = _r ;
                 sigma = _sigma ;
                 pas = _pas ;
                 dimension = _dimension ;
                 mu = r - ((sigma*sigma)/2.0) ;
                 T = pas*(dimension-1) ;
                 S = new double[_dimension] ;
                               }

02/03/2011, 22h32
Invité

Salut,
Ca n'as aucune valeur... Ici c'est pour un pseudo-problème de porté des variables. Il semblerait que dans la classe il existe des variables : r, sigma, pas, dimension. Sans les _ il aurait fallut écrire :

Code:

this->r = r;
02/03/2011, 22h42
tom31

merci ........
03/03/2011, 07h22
Joel F

ce code n'est aps standard car le standard proscrit l'utilsiation d'identifiants commencant par _ en les reservants a l'implementation du compilateur
03/03/2011, 09h45
Goten

Citation:

Envoyé par Joel F

ce code n'est aps standard car le standard proscrit l'utilsiation d'identifiants commencant par _ en les reservants a l'implementation du compilateur

Pour être précis, le standard proscrit l'utilisation d'un underscore suivi d'une majuscule et l'utilisation d'un double underscore suivit d'un majuscule ou d'une minuscule.

Mais une bonne régle est de pas utilisé d'underscore au début d'un identifiantn.
03/03/2011, 11h26
GeantVert13

A ce propos...

Hello,

Avez vous un lien pour des "coding rules" standards en ce qui concerne le c++ ?

j'avais trouvé ça :http://geosoft.no/development/cppstyle.html
qui préconise de mettre "_" en suffixe des membres (nomDeMembre_). J'ai trouvé ça relativement élégant.
Mais c'est un peu en contradiction avec ça :
http://www.possibility.com/Cpp/CppCodingStandard.html
qui préconise mNomDeMembre... que je trouve moins sexy. Je sais tout ça est très subjectif... on est d'accord, l'essentiel (et le plus dur) étant ; qu'une fois qu'on a choisi une convention, s'est de s'y tenir.

Merci
03/03/2011, 11h54
r0d

En fait, le plus souvent il faut s'adapter à un convention de nommage déjà existente.

Après, si on peut choisir celle qu'on veut, c'est effectivement très subjectif. Il y a tout de même quelques critères objectifs (les quelques recommandation de la norme, essayer de se différencier des libs standard, une écriture pas trop lourde), mais pas beaucoup. Et c'est évolutif aussi. Moi en ce moment j'utilise:
. les types (typedef, class, struct et fonctions): MonType
. les variables libres: ma_variable_libre
. les variables membres private et protected: ma_variable_membre_
. les espaces de nommage internes: MyNameSpace
. les espaces de nommages destinés à être exportés: MNS
. les variables membres publiques: MaVariableMembre (car je trouve que ça ressemble, sémantiquement parlant, aux propriétés de classe en C#)
09/03/2011, 10h31
3DArchi

Citation:

Envoyé par GeantVert13

Avez vous un lien pour des "coding rules" standards en ce qui concerne le c++ ?

(ordre sans importance)
http://www.chris-lott.org/resources/...l-rules-mm.pdf
http://www2.research.att.com/~bs/JSF-AV-rules.pdf
http://www.state-machine.com/doc/AN_...g_Standard.pdf
http://www.codingstandard.com/HICPPCM/index.html
http://www.possibility.com/Cpp/CppCodingStandard.html
http://geosoft.no/development/cppstyle.html
Les coding rules ne sont pas 'standards' mais un mélange de bonnes pratiques générales et de 'styles' propre à une équipe/entreprise/projet.

Pour le nommage, l'essentiel est d'être cohérent sur le projet/l'entreprise.
09/03/2011, 12h24
screetch
pour l'exemple donné, une liste d'initialisation aurait permis de résoudre le conflit
Code:

1 2 3 4 X::X(int x) : x(x) { }
10/03/2011, 11h02
r0d
Citation:
Envoyé par screetch

pour l'exemple donné, une liste d'initialisation aurait permis de résoudre le conflit

Code:

1 2 3 4 X::X(int x) : x(x) { }
Ha tiens, je ne savais pas. Et ça pourrait m'intéresser.
C'est dans le standard ça? Tous les compilos le gèrent correctement?
10/03/2011, 11h35
GeantVert13

Citation:

Envoyé par r0d

Ha tiens, je ne savais pas. Et ça pourrait m'intéresser.
C'est dans le standard ça? Tous les compilos le gèrent correctement?

C'est même fortement conseillé, puisque le constructeur va, de toute façon, initialiser les membres. s'il y a une liste d'initialisation, il ne va faire l'opération qu'une fois. Alors qu'avec tes assignations, il va initialiser avec des valeurs par défaut et ensuite faire tes assignations.
10/03/2011, 12h07
screetch

Citation:

Envoyé par r0d

Ha tiens, je ne savais pas. Et ça pourrait m'intéresser.
C'est dans le standard ça? Tous les compilos le gèrent correctement?

a ma connaissance, oui, bien que je n'aie jamais vraiment regardé. Ca marche sous intel C++, visual C++, GCC, suncc.

Il n'y a pas de conflit puisque c'est une liste d'initialisation: le premier x dans x(x) est forcément un membre de X (contrairement a x = x dans le corps qui est ambigü)

mais je ne sais pas si c'est ecrit quelque part.

Je l'utilise souvent car j'utilise a 99% les listes d'initialisations et j'essaye d'éviter le code dans le corps du constructeur, le résultat est souvent plus propre

@geantvert: r0d parlait specifiquement de la syntaxe

Code:

X() : member(member)

ou un paramètre pourrait avoir le même nom qu'un membre de la classe
10/03/2011, 12h14
r0d

Citation:

Envoyé par GeantVert13

C'est même fortement conseillé, puisque le constructeur va, de toute façon, initialiser les membres. s'il y a une liste d'initialisation, il ne va faire l'opération qu'une fois. Alors qu'avec tes assignations, il va initialiser avec des valeurs par défaut et ensuite faire tes assignations.

Oui je suis d'accord. Et puis la liste d'initilialisation a d'autres avantages.
Mais ma question portait sur le fait d'utiliser exactement le même identifiant pour le paramètre passé au constructeur et la variable membre.

edit: grilled by screetch :) (et merci pour la réponse)
10/03/2011, 12h21
Klaim

Le standard dit que le compilo doit chercher les noms du scope le plus petit (le block de code en cours - entre acolades) à la plus grande (espace global) pour trouver ce a quoi corresponds le dit nom.

En plus, selon là ou apparait le nom et selon comment il est utilisé, il est facile de différencier les fonctions des objets, du moins pour le compilateur. C'est parfois obscure pour les programmeurs qui du coup préfèrent marquer leurs variables avec une information de context, typiquement pour indiquer si c'est un objet membre d'une classe, ou encore statique, etc.

Mais effectivement pour le compilo c'est rarement ambigu (sauf le coup classique de la définition d'un objet qui ressemble trop a une déclaration de fonction...)

Si ça ne dérange pas les développeurs concerner, ne mettre aucune annotation de context peu marcher sans souci. Personnellement j'aime bien, mais je préfère quand même utiliser le prefix m_ pour les membres de classe, simplement pour aider l'auto-completion de mes outils de developpement.

D'ailleurs ils ont pas mal évolué, je vais tenter voir sans m_ si ils s'en sortent mieu qu'il y a quelques années...
10/03/2011, 14h40
GeantVert13

Citation:

Envoyé par screetch

@geantvert: r0d parlait specifiquement de la syntaxe

Code:

X() : member(member)

ou un paramètre pourrait avoir le même nom qu'un membre de la classe

... au temps pour moi !
10/03/2011, 17h10
screetch

Citation:

Envoyé par Klaim

Si ça ne dérange pas les développeurs concerner, ne mettre aucune annotation de context peu marcher sans souci. Personnellement j'aime bien, mais je préfère quand même utiliser le prefix m_ pour les membres de classe, simplement pour aider l'auto-completion de mes outils de developpement.

D'ailleurs ils ont pas mal évolué, je vais tenter voir sans m_ si ils s'en sortent mieu qu'il y a quelques années...

j'utilise m_ pour les membres protected ou private
j'utilise le nom sans m_ pour les membres publics (notemment les publics const) qui évitent de créer des getters et setters pour rien. Ces membres étant souvent initialisées avec une variable du même nom, ca ne pose pas de problème dans ce cas.
Mais sinon je supporte fortement le m_ :)
10/03/2011, 17h13
Klaim

Je suis la même logique mais j'hévite autant les getter et setters que les objets membres publiques, sauf dans des struct représentant des données "brutes".
10/03/2011, 17h25
screetch

hmmm c'est vrai que j'en ai pas des masses et que souvent ce sont en plus des membres const
10/03/2011, 17h35
Klaim

En fait j'ai remarqué que j'arrivais toujours a un de ces deux cas :

1. Finalement, je veux ajouter un controle d'accès à la variable et du coup ajouter une fonction d'accès dés le début évite un refactoring de tous les points d'accès. Souvent c'est parceque je ne veux l'accès en const mais aussi aucun accès en écriture. Exposer directement le membre fait que c'est le membre "hérite" implicitement du niveau d'accès de l'objet dans lequel il est contenu. Quand je ne veux pas que ce soit le cas, une fonction d'accès (écrite de manière à plus correspondre à un service/une action qu'un bete getter à un membre) est a priori l'unique solution.

2. Je veux que mon objet soit a) copiable (parceque contenu dans un vector par exemple) mais en même temps je veux qu'une fois créé l'objet soit impossible a modifier (autrement que par un hack moche et facile a repérer). Typiquement pour tout ce qui est messages/signaux/events. Dans ce cas, je met un constructeur qui assigne les valeurs des membres, puis je mets des accesseurs uniquement const. Je ne peux pas mettre les membre en const a cause de la contrainte de copie, donc au mieu je limite l'accès via une fonction qui elle est const, tout en gardant le membre modifiable en interne pour la copie.

Donc a part pour des données brutes, je me retrouve "toujours" à mettre en place des fonctions (et des types) dans les parties publiques, jamais des objets. Et comme je n'aime pas les getters, ça m'oblige a exposer uniquement le strict nécessaire, avec une interface presque finale (parcequ'elles ne le sont jamais si le projet dure assez longtemps).
10/03/2011, 17h48
r0d

Citation:

Envoyé par Klaim

(parcequ'elles ne le sont jamais si le projet dure assez longtemps).

chut, ne le dis pas trop fort, j'en connais qui croient encore que c'est possible de définir les interfaces au début d'un projet et de ne jamais les toucher... un des mes chefs y croit (il n'a jamais codé une ligne).

Sinon, il y a des cas où il est tout de même difficile de se passer d'accesseur, ou en faisant des détours qui serait pire qu'un bête Getxxx().
L'exemple typique c'est l'objet graphique manipulé par un moteur de rendu (il peut s'agir d'un widget dans un lib d'IHM, d'un SDL_Image, d'un objet 3D, etc.). Le moteur qui manipule cet objet aura besoin d'information de bases, typiquement le rectangle (ou parrallelépipède) englobant pour calculer les collisions xor superpositions. Prenons le cas d'un widget. Il faudra bien stocker la largeur et la hauteur du widget et le rendre accessible. Par contre, il ne faut pas qu'il soit modifiable par n'importe qui. Dans ce cas (et même si c'est implémenté par une classe mère), quoi de mieux qu'un bête GetWidth() et GetHeight()?
10/03/2011, 17h57
Flob90

<HS>
@Rod: Dans l'exemple que tu cites, on pourrait pas passer par friend (entre le moteur et widget) ou "inverser" le mécanisme, on ne passe pas le widget au moteur, mais le moteur au widget qui pourra donc passer les info qu'il veut ensuite ? (idée comme ca, pas réfléchie plus en profondeur)
</HS>
10/03/2011, 18h13
r0d

<HS>

Citation:

Envoyé par Flob90

@Rod: Dans l'exemple que tu cites, on pourrait pas passer par friend (entre le moteur et widget)

friend c'est ok si effectivement il n'y a que quelques classes qui auront besoin de cette donnée. Mais un moteur de rendu graphique ne peut malheureusement pas contenir dans une seule classe, et dans cet exemple particulier, il est difficile de faire en sorte que seules 2 ou 3 classes aient besoin de connaitre ce rectangle englobant.
Bien sûr, certains me dirons que si j'en arrive là c'est parce que j'ai fait des erreurs de conception, que je ne sais pas refactoriser mon code ou que je suis fainéant. Effectivement, dans la théorie on devrait pouvoir parvenir à une parfaite encapsulation et une sémantique 100% utile. Dans la pratique c'est pas toujours facile...

Citation:

Envoyé par Flob90

ou "inverser" le mécanisme, on ne passe pas le widget au moteur, mais le moteur au widget qui pourra donc passer les info qu'il veut ensuite ? (idée comme ca, pas réfléchie plus en profondeur)

Cette solution ne fonctionne pas car elle ne fait que déplacer le problème: celui qui calculer les collisions, qui que ce soit, aura besoin de connaitre les rectangles englobants de tous les objets qui doit gérer.

</HS>
10/03/2011, 18h40
Klaim

Oui les betes accesseurs sont des compromis parfois difficile a éviter.

Dans le pire des cas je fais des accesseurs sans verbes, genre machin.truc();
Dans l'idéal je transforme cela en verbe, mais plus on va vers des systèmes "basiques" plus c'est difficile de ne pas passer par des accesseurs betes. Typiquement les objets contenant uniquement des données (et peu de logique concernant ces données) sont candidates aux accesseurs.

Pour le reste il y a eurocardmaster... heu les fonctions de service plutot :D
10/03/2011, 18h45
3DArchi

Pour continuer sur le HS de r0d : V comme visiteur comme dirait l'autre camarade