Bonjour à tous !

La raison du sujet est que j'ai du mal à comprendre le pointeur this dans un cas. Je m'explique :

On crée une classe complexe avec deux arguments privés Re et Im.

On crée un opérateur == de type bool qui renvoie true s'ils sont identiques, sinon false.

Donc ça donne un truc du genre :

Bool complexe :: operator==(complexe C)
{return getre()==C.getre()&&getim()==C.getim();}

Jusque là c'est bon. Mais après on crée un autre opérateur, cette fois le contraire, !=.

Et dans la correction je trouve :

bool complexe::operator!=(complexe C)
{return
this->getre()!=C.getre()||this->Getim()!=C.getim()
;}

J'ai du mal à comprendre. Mais si je traduis ça donnerait "on retourne (vrai ou faux) cela : C.getre()... Dans ce cas this ne désigne pas du tout un pointeur... ?

Si quelqu'un pouvait éclairer ma lanterne ça serait sympa Merci d'avance !

En fait écrire "getre()" ou "this->getre()" revient exactement au même, this pointe sur l'objet en question. Par exemple si on instancie un complexe :

complexe nombre;

et qu'on utilise l’opérateur != avec celui-ci, this pointera vers l'adresse du premier octet de "nombre", bon après pour utiliser une méthode de cet objet ça ne sert pas à grand chose de l’écrire car vu que tu es dans la portée de celui-ci (complexe::) cela se fait automatiquement.
Ça peut être utile dans certains cas, par exemple si dans l'une des méthodes de complexe tu utilises une fonction qui prend un "complexe*" comme argument et que tu veux passer l'objet faisant appel à cette méthode, tu peux utiliser le pointeur this.

D'accord je vois, donc dans ce cas c'était inutile de s'en servir. Merci beaucoup

Note que l'on prefere souvent ne declarer qu'un seul operateur de comparaison: soit == soit !=. Ensuite on declare l'autre comme l'oppose du premier:

bool complexe :: operator==(complexe C)
{return getre()==C.getre()&&getim()==C.getim();}

bool complexe::operator!=(complexe C)
{return!this->operator==(C);}

Ca permet d'eviter d'avoir a == b ET a!= b en meme temps.

Note aussi que pour les fonctions de comparaison, on passe souvent un argument sous la forme d'une reference constante: "const Complexe &" afin d'eviter la copie de l'objet C en memoire.

Pour aller encore un peu plus loin, il est souvnet preferable de declarer les fonction de comparaison constante pour etre sur que l'on ne change pas la valeur de l'objet par inadvertence.
La correction devrait donc ressembler a:

bool complexe :: operator==(const complexe& C) const
{return getre()==C.getre()&&getim()==C.getim();}

bool complexe::operator!=(const complexe& C) const
{return!this->operator==(C);}

Ah d'accord effectivement cela permet pas mal de simplifications

Bon tant que j'y suis j'aurais une autre question mais rien à voir avec this.

Dans un annale on a deux classes : population avec deux arguments privés X et Y et une méthode f publique, et voltera avec comme arguments privés A et B.

Mais la méthode f doit utiliser les arguments privés des deux classes : elle doit renvoyer AX-BXY.

Comment fait-on ? Parce qu'on doit dire dans quelle classe on se situe pour utiliser les arguments privés de cette classe, mais là on en a deux. Apparemment ce n'est pas l'héritage qu'il faut utiliser.

Vous voyez ce que je veux dire ?

Soit tu utilises des méthodes publiques qui renvoient les membres privés en question, soit tu déclares ces deux classes comme étant "amies" (avec le keyword friend).

Ben justement dans l'annale ils ne demandaient pas de telles méthodes donc je me demandais. Donc ça devait être le friend, mais on l'a pas vu ce semestre, ce n'est peut-être plus dans le programme. En tous cas merci

Je pense qu'il faut utiliser ceci : http://casteyde.christian.free.fr/cpp/cours/online/x3010.html

PS: j'ai pris la première réponse de google sur le sujet, à toi de voir s'il n'y a pas plus clair ailleurs.

(le cours de chistian casteyde est bien structure si ma memoire est bonne)

Il précise même que c'est à utiliser avec modération et que ça peut mettre en évidence un biais de conception, merci Christian d'éviter que vos lecteurs ne court-circuitent la notion même d'encapsulation en POO.

J'ai toujours vu "friend" en C++ comme l'equivalent du niveau de protection "package" en java. Je suis d'accord qu'il faut faire attention, mais c'est parfois pratique.