Discussion :

[Bktero]

Bonjour,

J'ai une classe RangeWidget qui possède un champ float max_m. J'ai demandé à CLion de générer un setter pour ce champ. Voici le code généré :

Code :

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

1
2
3
4
void RangeWidget::setMax_m(float max_m)
{
    RangeWidget::max_m = max_m;
}

Je me serais attendu à cette écriture :

Code :

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

1
2
3
4
void RangeWidget::setMax_m(float max_m)
{
    this->max_m = max_m;
}

J'allais dire "je ne connaissais pas cette écriture Class::champ" mais en y réfléchissant bien, je l'avais déjà vu pour éviter des conflits lors d'héritage multiple.

Ma question est très simple : faut-il préférer this->champ ou Class::champ ?

Merci !

[dalfab]

Il y même 4 possibilités pour un membre non statique dans une fonction membre non statique s'il n'y a pas d'ambiguité.

Code :

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

1
2
3
4
this->RangeWidget::max_m;
RangeWidget::max_m;
this->max_m;
max_m;

Laquelle est préférable : la dernière, c'est clair et net. En ayant évité d'avoir un paramètre de même nom.
Sinon j'ai une préférence pour this->max_m s'il n'y a pas d'ambiguïté et sur la première sinon.

[ternel]

En théorie, Class::champ est un nom qualifié, recherché différement des noms non qualifiés.
Le compilateur doit chercher le scope Class puis parmi les variables de ce scope. Et si le scope est une classe, vérifier que *this en dérive.

this->champ au contraire, est un accès par un nom non qualifié, mais dans *this uniquement.

D'un point de vue strictement lié à la norme, this-> est plus efficace, car saute l'étape de recherche dans les variables locales.
S'il y a une différence, c'est uniquement sur le temps de compilation.

En pratique, il est hautement probable que la différence soit nulle, le compilateur pouvant avoir en interne une table de noms connus, comprenant notamment les noms trouvés dans *this.

Par contre, pour la lecture du code, le plus clair est encore la troisième solution: utiliser un préfixe ou un suffixe pour les membres (m_champ ou champ_).
L'effet est alors équivalent à Class::champ.

[foetus]

l'écriture RangeWidget::max_m; n'est pas pour appeler un attribut statique ?


Et sinon :: (les 2 2 points) c'est l'opérateur de résolution de portée

[ternel]

Normalement, c'est plus pour ca, mais je crois bien que cela fonctionne.
Même si, en me creusant la tête, je ne me souviens de m'en être servi que pour des fonctions.

d'après cppreference.com, le "qualified_lookup" peut chercher un "class member (including static and non-static functions, types, templates, etc)".
Donc, oui, ca doit fonctionner

[foetus]

Ouais cela doit fonctionner, parce que de souvenirs , c'est l'écriture que l'on utilise pour résoudre les problèmes d'héritage multiple en losange, ... en spécifiant quelle classe mère on choisit

[bacelar]

Je pense que les concepteurs/implémenteurs de CLion ont pris la 2ème écriture car cela donne une implémentation la plus "robuste".
La plus simple, la 4ème, est sujet aux collisions de noms entre l'argument et le champ.
La plus "naturelle", la 3ème, oblige l'IDE à déterminer si le champ est statique ou pas, et le code pètera si l'utilisateur change la nature static/d'instance du champs.
La 1ère est plus complexe (mais en code auto-généré, on sent fout) et dispose des mêmes limitations que la 3ème.

[Pyramidev]

La plus "naturelle", la 3ème, oblige l'IDE à déterminer si le champ est statique ou pas, et le code pètera si l'utilisateur change la nature static/d'instance du champs.
La 1ère est plus complexe (mais en code auto-généré, on sent fout) et dispose des mêmes limitations que la 3ème.

Non. L'écriture this->membreStatique est valide, tout comme ptrVersObj->membreStatique et obj.membreStatique. Et cela vaut à la fois pour les variables membres statiques et les fonctions membres statiques.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#include <iostream>
 
struct Foo {
	static int bar;
	static void baz() { bar = 3; }
	Foo() {
		this->baz();
		this->Foo::baz();
		this->bar = 0;
		this->Foo::bar = 2;
	}
};
 
int Foo::bar = 1;
 
int main()
{
	std::cout << Foo::bar; // prints "1"
	Foo foo;
	std::cout << foo.bar; // prints "2"
	foo.baz();
	std::cout << (&foo)->bar; // prints "3"
	(&foo)->baz();
	return 0;
}

A part ça, par rapport au sujet du fil, personnellement, je préfère préfixer toutes les variables membres privées par m_ pour les distinguer des paramètres de fonction.

[foetus]

je préfère préfixer toutes les variables membres privées par m_ pour les distinguer des paramètres de fonction.

je ne préfère pas préfixer toutes les variables membres privées, mais préfixer tous les paramètres de fonction par new_, param_, input_, ...

[koala01]

Salut,

je ne préfère pas préfixer toutes les variables membres privées, mais préfixer tous les paramètres de fonction par new_, param_, input_, ...

Humm...

1. new ne semble intéressant que lorsque le paramètre est destiné à redéfinir une valeur.
2. param_ n'apporte strictement rien à la lecture de la signature car on se doute bien que c'est un paramètre
3. input_ pareil : tout paramètre étant forcément une donnée en entrée (et éventuellement une donnée en sortie, bien que ce soit déconseillé)

A choisir, je préfère préfixer ou suffixer les données membres, de manière à garder les identifiants non préfixés pour les paramètres, de manière à ce que leur identifiant indique leur raison d'être

[Pyramidev]

param_ n'apporte strictement rien à la lecture de la signature car on se doute bien que c'est un paramètre

Par contre, dans certains milieux, cela peut avoir un intérêt dans la lecture de l'implémentation d'une fonction.

Tant que l'implémentation reste courte, param_ ne sert à rien à part alourdir la lecture. Mais, une fois que des développeurs auront bien massacré le code en transformant la petite fonction de départ en fonction de 200 km, alors les préfixes param_ aideront un petit peu les pauvres lecteurs du code.

Dans le code que je maintiens, dans certaines fonctions, tous les paramètres sont préfixés par p, par exemple pTrucMachin.

D'ailleurs, par le passé, Oncle Bob préfixait :

• les paramètres par the
• les variables locales par a ou an,
• les variables membres non statiques par its (ou is pour les booléens) et
• les variables membres statiques par their.

Source : http://wiki.c2.com/?UncleBobsNamingConventions

Cela dit, personnellement, je n'écris pas de préfixe pour les paramètres de fonction.

[Bktero]

Merci pour vos commentaires ! Je passe en résolu.

PS : Il va sans dire que j'ai modifié le code généré en ceci :

Code :

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

1
2
3
4
void RangeWidget::setMax(float max)
{
    max_m = max;
}