Discussion :

[tom31]

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 :

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

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] ;
                               }

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

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

this->r = r;

[tom31]

merci ........

[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

[Goten]

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.

[GeantVert13]

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

[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#)

[3DArchi]

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.

[screetch]

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

Code :

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

1
2
3
4
X::X(int x)
: x(x)
{
}

[r0d]

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

Code :

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

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?

[GeantVert13]

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.

[screetch]

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 :

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

X() : member(member)

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

[r0d]

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)

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

[GeantVert13]

@geantvert: r0d parlait specifiquement de la syntaxe

Code :

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

X() : member(member)

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

... au temps pour moi !

[screetch]

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_

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

[screetch]

hmmm c'est vrai que j'en ai pas des masses et que souvent ce sont en plus des membres const

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

[r0d]

(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()?