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.