Quand utilisez-vous le mot-clé «this»? [fermé]

249

J'étais curieux de savoir comment d'autres personnes utilisent le mot - clé this . J'ai tendance à l'utiliser dans les constructeurs, mais je peux également l'utiliser dans toute la classe dans d'autres méthodes. Quelques exemples:

Chez un constructeur:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

Autre part

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}
Magic Hat
la source
2
J'ai trouvé de bons exemples lorsque vous avez vraiment besoin this de MSDN. Veuillez suivre ce lien ... ;-)
Matt
12
Si vous devez comprendre et optimiser ou réécrire quelqu'un d'autre, surtout du code mal écrit que vous seriez heureux d'avoir thisou tout autre qualificatif de sorte que d'un simple regard vous connaissez la portée de la variable (Qualificateurs de classe spécialement omis pour les constantes (même package ou hiérarchie) ou super/ basequalificatifs). Et utiliser la syntaxe couramment utilisée comme _foone semble pas si élégant pour moi. Presser _pour intellisense prend plus de temps que d'entrer this. Et pourquoi s'embêter du tout! Avec les fonctions de formatage à sauvegarde automatique d'Eclipse, pas besoin _au cas où vous auriez oublié le qualificatif.
djmj
Après avoir lu les réponses et commentaires ci-dessous, ainsi que la documentation MSDN: docs.microsoft.com/en-us/previous-versions/visualstudio/… sur le mot-clé this qui n'a pas été mis à jour depuis 6 ans, je suggère pour ne jamais utiliser le mot - clé this . C'est inutile. Ne faites pas les paramètres du même nom, c'est déroutant et stupide. Pourquoi ferais-tu ça? De plus, ne passent pas l'instance à utiliser ce , il est également source de confusion et stupide.
Yusha

Réponses:

218

Il existe plusieurs utilisations de ce mot clé en C #.

  1. Pour qualifier les membres cachés par un nom similaire
  2. Pour qu'un objet se passe en paramètre à d'autres méthodes
  3. Pour qu'un objet se renvoie d'une méthode
  4. Pour déclarer des indexeurs
  5. Pour déclarer des méthodes d'extension
  6. Pour passer des paramètres entre constructeurs
  7. Pour réaffecter en interne une valeur de type (struct) de valeur .
  8. Pour appeler une méthode d'extension sur l'instance actuelle
  9. Pour se lancer dans un autre type
  10. Pour chaîner des constructeurs définis dans la même classe

Vous pouvez éviter la première utilisation en n'ayant pas de variables membres et locales avec le même nom dans la portée, par exemple en suivant les conventions de dénomination courantes et en utilisant des propriétés (cas Pascal) au lieu de champs (cas chameau) pour éviter d'entrer en collision avec des variables locales (également chameau) Cas). En C # 3.0, les champs peuvent être facilement convertis en propriétés à l'aide de propriétés implémentées automatiquement .

Jakub Šturc
la source
49
8. Pour invoquer une méthode d'extension sur l'instance actuelle ( this.Foo();fonctionnera, mais Foo()ne fonctionnera pas)
Marc Gravell
4
Aussi pour se convertir à un autre type, par exemple une méthode implémentée explicitement sera appelée comme ((ICollection<T>)this).Add(bla).
nawfal
4
Pour chaîner la construction à un autre constructeur défini dans le même type. public ClassName(...) : this(...).
Lasse V. Karlsen
1
@Anand, cela n'affectera en rien les performances au moment de l'exécution. En supposant qu'il n'y ait aucune ambiguïté, la sortie du compilateur est la même, que vous écriviez, par exemple this.someField = someValueou someField = someValue. Cela pourrait affecter les performances du compilateur, car le compilateur analysera le code source différemment, mais toute différence serait sûrement négligeable.
phoog
7
Vous pouvez éviter le premier problème en accédant aux champs via les propriétés uniquement si vous respectez une convention de style selon laquelle les propriétés ne peuvent pas avoir les mêmes noms que les paramètres. Il se trouve que la convention de style C # courante répond à cette exigence. Cependant, tout C # n'est pas écrit en vertu de cette convention. Il n'y a rien d'inhérent aux propriétés en soi qui rendrait le thismot - clé inutile; un paramètre constructeur appelé xmasquera un membre appelé, xqu'il s'agisse d'un champ, d'une propriété ou d'un événement, d'ailleurs.
phoog
246

Je ne veux pas que cela semble sarcastique, mais cela n'a pas d'importance.

Sérieusement.

Regardez les choses qui sont importantes: votre projet, votre code, votre travail, votre vie personnelle. Aucun d'entre eux n'aura de succès si vous utilisez ou non le mot-clé "this" pour qualifier l'accès aux champs. Ce mot-clé ne vous aidera pas à expédier à temps. Cela ne réduira pas les bogues, cela n'aura aucun effet appréciable sur la qualité ou la maintenabilité du code. Cela ne vous procurera pas d'augmentation ni ne vous permettra de passer moins de temps au bureau.

C'est vraiment juste une question de style. Si vous aimez "ceci", utilisez-le. Si vous ne le faites pas, alors ne le faites pas. Si vous en avez besoin pour obtenir une sémantique correcte, utilisez-la. La vérité est que chaque programmeur a son propre style de programmation. Ce style reflète les notions de ce programmeur particulier de ce à quoi devrait ressembler le "code le plus esthétique". Par définition, tout autre programmeur qui lit votre code aura un style de programmation différent. Cela signifie qu'il y aura toujours quelque chose que vous avez fait que l'autre gars n'aime pas ou aurait fait différemment. À un moment donné, un gars va lire votre code et se plaindre de quelque chose.

Je ne m'en inquiéterais pas. Je voudrais juste m'assurer que le code est aussi esthétique que possible selon vos propres goûts. Si vous demandez à 10 programmeurs comment formater le code, vous obtiendrez environ 15 opinions différentes. Il vaut mieux se concentrer sur la façon dont le code est factorisé. Les choses sont-elles abstraites correctement? Ai-je choisi des noms significatifs pour les choses? Y a-t-il beaucoup de duplication de code? Existe-t-il des moyens de simplifier les choses? Je pense que le fait de bien faire ces choses aura le plus grand impact positif sur votre projet, votre code, votre travail et votre vie. Par coïncidence, cela fera probablement grogner l'autre gars le moins. Si votre code fonctionne, est facile à lire et est bien pris en compte, l'autre gars ne va pas examiner comment vous initialisez les champs. Il va juste utiliser votre code, s'émerveiller de sa grandeur,

Scott Wisniewski
la source
35
Le thismot-clé est sémantiquement significatif. Voir le commentaire de @ JasonBunting ci-dessous. Vous confondez la surutilisation stylistique de thisson but réel. Votre remarque n'est pas seulement désinvolte, elle est fausse!
Dan Barowy
12
Si vous en avez l'occasion, vous voudrez peut-être relire ma réponse. Je parle de l'utiliser dans les cas où cela est nécessaire pour une sémantique correcte. Vous pourriez également vouloir examiner la question d'origine. Il montre l'utilisation dans des exemples où ce n'est pas sémantiquement nécessaire. Donc, je ne sais pas exactement ce que j'ai dit qui était "faux". Ma réponse n'est certainement pas désinvolte.
Scott Wisniewski
9
Savez-vous comment me semble votre réponse? Entre les lignes, je lis "Comment osez-vous poser une question comme celle-ci?" - Ce n'est vraiment pas constructif à mon avis. Personne ne sait tout - c'est pourquoi nous avons Stackoverflow: pour aider les autres et obtenir de l'aide. Certains sujets que vous connaissez, certains en connaissent d'autres. Aidez-vous les uns les autres, ne vous battez pas les uns avec les autres. S'il te plait penses-y.
Matt
9
Je ne veux pas paraître sarcastique, mais c'est l'une des pires réponses à ce jour. Je ne vois pas en quoi il est utile de comparer cela à votre travail ou à votre vie personnelle. Ce n'est pas parce que certaines choses sont moins importantes que d'autres qu'elles ne sont pas importantes . Avoir un style de programmation cohérent n'est pas sans importance (lire un livre sur la lisibilité / maintenabilité du code de votre choix).
aioobe
4
Je pense que vous avez peut-être mal compris mon point. Ce n'est pas que «avoir un style cohérent» soit mauvais. Je ne dis rien à cet effet. C'est que la question op de "mon guide de style devrait-il imposer ceci". comme préfixe pour tous les accès aux champs? " est arbitraire et capricieux.
Scott Wisniewski
96

Je ne l'utilise qu'en cas de nécessité absolue, c'est-à-dire lorsqu'une autre variable en observe une autre. Comme ici:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

Ou comme le souligne Ryan Fox, lorsque vous devez passer cela en paramètre. (Les variables locales ont priorité sur les variables membres)

Corey
la source
6
Dans ce cas, pourquoi ne pas simplement donner des noms différents aux variables d'entrée du constructeur?
wz366
54

Personnellement, j'essaie de toujours utiliser cela lorsque je me réfère à des variables membres. Il aide à clarifier le code et à le rendre plus lisible. Même s'il n'y a pas d'ambiguïté, quelqu'un qui lit mon code pour la première fois ne le sait pas, mais s'il voit que cela est utilisé de manière cohérente, il saura s'il regarde une variable membre ou non.

Brandon Wood
la source
9
mais si vous oubliez de l'utiliser un jour, ils seront confus
surfez
2
@surfen qui peut être évité par des vérifications de style supplémentaires, par exemple en Java, vous pouvez utiliser Checkstyle et l'exécuter après une construction complète (et dans tout langage itératif / OO populaire, il y aura des outils similaires)
Maarten Bodewes
5
@ surfez comme si vous l'oubliez dans des cas ambigus. Je peux casser tout argument en disant "mais si vous oubliez ...".
Askolein
6
La plupart des gens semblent ne jamais lire, optimiser ou réécrire le code de quelqu'un d'autre! Les qualifiés sont économiseurs de temps et de motivation! Sans qualificatif, c'est comme par magie si vous voyez une ligne de code arbitraire. Vous perdez donc tout votre temps à vérifier d'où viennent ces variables.
djmj
3
Je sais que c'est un très vieux post, mais je ne peux pas m'empêcher de commenter l'ironie de cette réponse (avec laquelle je suis d'accord). Dans le Jihad contre la mauvaise notation hongroise, quiconque osait préfixer ses variables membres avec "m_" était rapidement mis au pilori parce que distinguer les variables membres n'était tout simplement pas utile ou nécessaire.
Michael J.
38

Je l'utilise chaque fois que je fais référence à une variable d'instance, même si je n'en ai pas besoin. Je pense que cela rend le code plus clair.

Thomas Owens
la source
Je veux distinguer les variables de classe autant que possible, donc le code est plus clair. J'ai utilisé le préfixe m_ (variable membre), par exemple la chaîne privée m_name. Maintenant, je l'utilise par exemple si j'ai la classe Test {chaîne privée a; public someMethod () {this.a = "foo"; }}
haut débit
36

Je ne peux pas croire que toutes les personnes qui disent que l’utiliser est toujours une «meilleure pratique», etc.

Utilisez "ceci" en cas d'ambiguïté, comme dans l'exemple de Corey ou lorsque vous devez passer l'objet en paramètre, comme dans l'exemple de Ryan . Il n'y a aucune raison de l'utiliser autrement car être capable de résoudre une variable basée sur la chaîne de portée doit être suffisamment clair pour que les variables qualificatives avec lui ne soient pas nécessaires.

EDIT: La documentation C # sur "ceci" indique une autre utilisation, en plus des deux que j'ai mentionnées, pour le mot-clé "this" - pour déclarer les indexeurs

EDIT: @Juan: Huh, je ne vois aucune incohérence dans mes déclarations - il y a 3 cas où j'utiliserais le mot-clé "this" (comme documenté dans la documentation C #), et ce sont des moments où vous en avez réellement besoin . Coller "ceci" devant des variables dans un constructeur quand il n'y a pas d'observation est simplement une perte de frappe et une perte de temps en le lisant, cela n'apporte aucun avantage.

Jason Bunting
la source
21
@ JasonBunting : Vous ne pouvez pas faire quelque chose parfois et pas d'autres ... il est source de confusion ... J'espère ne jamais travailler dans votre Code Vous ne pouvez pas toujours Asume qu'une personne qui lit votre code à l'avenir comprendrai ce que vous écrit, vous devez être aussi clair que possible, et une façon d'y parvenir est d'être cohérent
juan
@juan, 10 ans plus tard. Vous pensez toujours que l'utilisation de "ceci" est une bonne pratique? :)
Scott Adams
2
@ScottAdams Je crois toujours à la cohérence et à la clarté, oui
juan
Qu'en est-il de la détermination de la portée d'une variable (qu'elle soit locale ou variable membre) simplement en la regardant? N'est-ce pas justifié à cette fin? Ou vous voulez dire que si nous écrivons des méthodes plus petites, il serait de toute façon assez facile de comprendre la portée de la variable?
BornToCode
27

Je l'utilise chaque fois que StyleCop me le demande. StyleCop doit être respecté. Oh oui.

Ian Nelson
la source
1
Et ReSharper me dit de ne pas l'utiliser. Un peu déroutant lorsque j'utilise à la fois StyleCop et ReSharper en même temps :) Mais je m'appuie sur la réponse de Coreys ci-dessus, pour utiliser le mot-clé «this» uniquement lorsque cela est absolument nécessaire.
Gunnar
@Gunnar, il y a une option pour désactiver la suppression de "ceci" redondant. dans R #
Winger Sendon
@EmperorAiman ​​- Oui, je sais. Mon point était que ces deux outils de mise en forme populaires sont par défaut, suggérant deux choses différentes et qui peuvent prêter à confusion. "Être ou ne pas être ..." :)
Gunnar
11

Chaque fois que vous avez besoin d'une référence à l'objet actuel.

Un scénario particulièrement pratique est lorsque votre objet appelle une fonction et veut se passer dedans.

Exemple:

void onChange()
{
    screen.draw(this);
}
Ryan Fox
la source
7

J'ai tendance à l'utiliser partout aussi, juste pour m'assurer qu'il est clair que ce sont des membres d'instance avec lesquels nous avons affaire.

Philippe
la source
5

Je l'utilise partout où il pourrait y avoir une ambiguïté (évidemment). Non seulement l'ambiguïté du compilateur (ce serait nécessaire dans ce cas), mais aussi l'ambiguïté pour quelqu'un qui regarde le code.

Le Schtroumpf
la source
5

Une autre utilisation assez rare du mot clé this est lorsque vous devez appeler une implémentation d'interface explicite à partir de la classe d'implémentation. Voici un exemple artificiel:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}
Paul Batum
la source
4

Voici quand je l'utilise:

  • Accès aux méthodes privées depuis la classe (pour différencier)
  • Passer l'objet courant à une autre méthode (ou en tant qu'objet émetteur, en cas d'événement)
  • Lors de la création de méthodes d'extension: D

Je ne l'utilise pas pour les champs privés car je préfixe les noms de variable de champ privé avec un trait de soulignement (_).

Vaibhav
la source
4

[C ++]

Je suis d'accord avec la brigade "utilisez-le quand vous devez". Décorer le code inutilement avec ce n'est pas une bonne idée car le compilateur ne vous avertira pas lorsque vous oubliez de le faire. Cela introduit une confusion potentielle pour les personnes qui s'attendent à ce que cela soit toujours là, c'est-à-dire qu'elles devront y penser .

Alors, quand l'utiliseriez-vous? Je viens de jeter un œil à du code aléatoire et j'ai trouvé ces exemples (je ne juge pas si ce sont de bonnes choses à faire ou non):

  • Passer "vous-même" à une fonction.
  • Assigner "vous-même" à un pointeur ou quelque chose comme ça.
  • Lancer, c'est-à-dire monter / descendre (sûr ou non), rejeter la constance, etc.
  • Le compilateur a imposé la désambiguïsation.
pseudo
la source
3

Vous devez toujours l'utiliser, je l'utilise pour différencier les champs et paramètres privés (car nos conventions de dénomination stipulent que nous n'utilisons pas de préfixes pour les noms de membres et de paramètres (et ils sont basés sur des informations trouvées sur Internet, donc je considère qu'un meilleur entrainement))

juan
la source
3

Je l'utilise lorsque, dans une fonction qui accepte une référence à un objet du même type, je veux préciser parfaitement à quel objet je fais référence, où.

Par exemple

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(contre)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

En un coup d'œil à quoi l'AABB fait right()référence? L' thisajoute un peu de clarificateur.

bobobobo
la source
3

Dans la réponse de Jakub Šturc, son numéro 5 sur la transmission de données entre constructeurs pourrait probablement utiliser une petite explication. C'est dans la surcharge des constructeurs et c'est le seul cas où l'utilisation de thisest obligatoire. Dans l'exemple suivant, nous pouvons appeler le constructeur paramétré à partir du constructeur sans paramètre avec un paramètre par défaut.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

J'ai trouvé que c'était une fonctionnalité particulièrement utile à l'occasion.

Cyberherbalist
la source
2

J'ai pris l'habitude de l'utiliser librement dans Visual C ++, car cela déclencherait ceux d'IntelliSense. J'appuie sur la touche «>», et je suis paresseux. (et sujet aux fautes de frappe)

Mais j'ai continué à l'utiliser, car je trouve pratique de voir que j'appelle une fonction membre plutôt qu'une fonction globale.

JohnMcG
la source
1

J'ai tendance à souligner les champs avec _, donc je n'ai jamais vraiment besoin de l'utiliser. De plus, R # a tendance à les refactoriser de toute façon ...

JamesSugrue
la source
1

Je assez bien utiliser que ce lorsque vous faites référence une propriété de type à l' intérieur du même type. Comme un autre utilisateur mentionné, je souligne aussi les champs locaux pour qu'ils soient visibles sans avoir besoin ce .

akmad
la source
1

Je l'utilise uniquement lorsque cela est nécessaire, sauf pour les opérations symétriques qui, en raison du polymorphisme à argument unique, doivent être mises dans les méthodes d'un côté:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 
Pete Kirkham
la source
1

[C ++]

ceci est utilisé dans l'opérateur d'affectation où la plupart du temps vous devez vérifier et éviter des choses étranges (involontaires, dangereuses ou simplement une perte de temps pour le programme) comme:

A a;
a = a;

Votre opérateur d'affectation sera écrit:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}
Empileur
la source
1

this sur un compilateur C ++

Le compilateur C ++ recherchera silencieusement un symbole s'il ne le trouve pas immédiatement. Parfois, la plupart du temps, c'est bien:

  • en utilisant la méthode de la classe mère si vous ne l'avez pas surchargée dans la classe enfant.
  • la promotion d'une valeur d'un type dans un autre type

Mais parfois, vous ne voulez tout simplement pas que le compilateur devine. Vous voulez que le compilateur récupère le bon symbole et pas un autre.

Pour moi , ces moments sont ceux où, au sein d'une méthode, je souhaite accéder à une méthode membre ou à une variable membre. Je ne veux simplement pas qu'un symbole aléatoire soit ramassé simplement parce que j'ai écrit à la printfplace de print. this->printfn'aurait pas compilé.

Le fait est que, avec les bibliothèques héritées C (§), le code hérité écrit il y a des années (§§), ou tout ce qui pourrait arriver dans une langue où le copier / coller est une fonction obsolète mais toujours active, parfois, en disant au compilateur de ne pas jouer l'esprit est une excellente idée.

Ce sont les raisons que j'utilise this.

(§) c'est toujours une sorte de mystère pour moi, mais je me demande maintenant si le fait que vous incluez l'en-tête <windows.h> dans votre source, soit la raison pour laquelle tous les symboles de bibliothèques C hérités vont polluer votre espace de noms global

(§§) se rendre compte que "vous devez inclure un en-tête, mais que l'inclusion de cet en-tête cassera votre code car il utilise une macro stupide avec un nom générique" est l'un de ces moments de roulette russe de la vie d'un codeur

paercebal
la source
1

'ce.' aide à trouver des membres sur «cette» classe avec beaucoup de membres (généralement en raison d'une chaîne d'héritage profonde).

Frapper CTRL + Espace n'aide pas à cela, car il comprend également des types; où-comme «ceci». inclut les membres UNIQUEMENT.

Je le supprime généralement une fois que j'ai ce que je recherchais: mais c'est juste mon style qui perce.

En termes de style, si vous êtes un solitaire - vous décidez; si vous travaillez pour une entreprise, respectez la politique de l'entreprise (regardez ce qui se passe dans le contrôle des sources et voyez ce que font les autres). En termes d'utilisation pour qualifier les membres, ni l'un ni l'autre n'a tort ou raison. La seule mauvaise chose est l'incohérence - c'est la règle d'or du style. Laissez les autres à la cueillette. Passez votre temps à réfléchir à de vrais problèmes de codage - et évidemment à coder - à la place.

Jonathan C Dickinson
la source
1

Je l'utilise chaque fois que je le peux. Je crois que cela rend le code plus lisible, et plus de code lisible équivaut à moins de bugs et plus de maintenabilité.


la source
1

Lorsque vous êtes plusieurs développeurs travaillant sur la même base de code, vous avez besoin de quelques directives / règles de code. Là où je travaille, nous avons souhaité utiliser «ceci» sur les champs, les propriétés et les événements.

Pour moi, il est logique de le faire comme ça, cela rend le code plus facile à lire lorsque vous différenciez les variables de classe et les variables de méthode.

Paw Baltzersen
la source
0

Cela dépend de la norme de codage sous laquelle je travaille. Si nous utilisons _ pour désigner une variable d'instance, alors "ceci" devient redondant. Si nous n'utilisons pas _, j'ai tendance à l'utiliser pour désigner une variable d'instance.

Dan Blair
la source
0

Je l'utilise pour invoquer Intellisense tout comme JohnMcG , mais je vais revenir en arrière et effacer "this->" quand j'aurai fini. Je suis la convention Microsoft de préfixer les variables membres avec "m_", donc le laisser comme documentation serait juste redondant.

Mark Ransom
la source
0

1 - Idiome commun de définition de Java:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - Lors de l'appel d'une fonction avec cet objet en paramètre

notifier.addListener(this);
svelte
la source
0

Il y a une utilisation qui n'a pas déjà été mentionnée en C ++ et qui n'est pas de faire référence au propre objet ou de lever l'ambiguïté d'un membre d'une variable reçue.

Vous pouvez utiliser thispour convertir un nom non dépendant en un nom dépendant d'argument à l'intérieur de classes de modèles héritant d'autres modèles.

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

Les modèles sont compilés avec un mécanisme à deux passes. Lors de la première passe, seuls les noms non dépendants des arguments sont résolus et vérifiés, tandis que les noms dépendants ne sont vérifiés que pour leur cohérence, sans réellement remplacer les arguments du modèle.

À cette étape, sans réellement remplacer le type, le compilateur n'a presque aucune information de ce qui base<T>pourrait être (notez que la spécialisation du modèle de base peut le transformer en types complètement différents, même des types non définis), donc il suppose simplement qu'il s'agit d'un type . À ce stade, l'appel non dépendant fqui semble naturel au programmeur est un symbole que le compilateur doit trouver en tant que membre derivedou dans des espaces de noms fermés - ce qui ne se produit pas dans l'exemple - et il se plaindra.

La solution consiste à transformer le nom non dépendant fen un nom dépendant. Cela peut être fait de deux manières, en indiquant explicitement le type où il est implémenté ( base<T>::f- l'ajout de base<T>rend le symbole dépendant Tet le compilateur supposera simplement qu'il existera et reporte la vérification réelle de la deuxième passe, après substitution d'argument.

La deuxième façon, beaucoup de trieur si vous héritez de modèles qui ont plus d'un argument, ou des noms longs, consiste simplement à ajouter un this->avant le symbole. Comme la classe de modèle que vous implémentez dépend d'un argument (dont il hérite base<T>) this->dépend de l'argument, et nous obtenons le même résultat: this->fest vérifié au deuxième tour, après la substitution des paramètres du modèle.

David Rodríguez - dribeas
la source
-2

Vous ne devez pas utiliser "ceci" à moins que vous ne deviez absolument le faire.

Il y a une pénalité associée à une verbosité inutile. Vous devez vous efforcer d'obtenir du code qui est exactement aussi long qu'il doit l'être, et non plus.

dicroce
la source