Surcharge d'opérateur unaire

Version imprimable

01/06/2012, 11h45
raf_gug

Surcharge d'opérateur unaire
Salut à tous!
Je cherche à surcharger l'opérateur unaire - dans un cadre d'héritage. Je voudrais faire quelque chose comme cela:
Code:

1 2 3 4 5 6 7 8 9 class Number_template { virtual Number_template operator-( ); }; class Number : public Number_template { Number operator-( ); };
Apparemment, pour que cela fonctionne, je devrais retourner non pas un Number mais un pointeur vers un Number. Mais je ne vois pas trop comment faire.

Quelqu'un à une idée?

Merci!

Rafael
01/06/2012, 12h06
mitkl

un peu de cette manière : http://cpp.developpez.com/faq/cpp/?p...URCHARGE_pp_mm
01/06/2012, 12h08
raf_gug

Merci pour ta réponse.

J'y ai pensé mais ce qui change fondamentalement (je pense, mais peut être que je passe à côté de quelque chose), c'est que mon opérateur unaire ne modifie pas l'objet, donc je peux pas retourner *this. Du coup, je vois pas trop sur quoi retourner un pointeur...

Pourquoi devrais-tu retourner un pointeur ?
Habituellement l'opérateur unaire de négation renvoie par copie un nouvel objet.

Code:

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
26
27
28
29
30
31
32
33
 
#include <iostream>
 
class A
{
    int m_x;
 
public:
 
    A(int x)
    {
        m_x = x;
    }
 
    int getx() const
    {
        return m_x;
    }
 
    A operator-() const
    {
        return A(-m_x);
    }
 
};
 
int main(int argc, char **argv)
{
    A a(3);
    std::cout << "a.getx() : " << a.getx() << std::endl;
    std::cout << "-a.getx() : " << (-a).getx() << std::endl;
    return 0;
}

compile et donne à l'exécution :

Code:

1
2
a.getx() : 3
-a.getx() : -3

01/06/2012, 12h28
raf_gug

valAa: car je fais de l'héritage. J'ai l'impression que sinon cela ne fonctionne pas (car les méthodes n'ont plus la même signature).

Ceci devrait marcher :

Code:

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
26
27
28
29
30
31
32
33
34
 
//soit A la classe mère.
 
//dans A :
virtual const A operator-(const A & a) const
    {
        /* tu définis un constructeur qui prenne en paramètre un const A & et un const A &
qui construise ton objet comme tu le souhaites. */
        return A(*this, a);
    }
 
//dans la classe fille :
 const [Type Classe Fille] operator-(const A & a) const
    {
        /* tu définis un constructeur qui prenne en paramètre un const [Type Classe Fille] & et un const A &
qui construise ton objet comme tu le souhaites. */
        return [Type Classe Fille](*this, a);
    }
 
OU
 
//dans A :
virtual const A operator-() const
    {
        /* tu définis le constructeur selon ce qui t'arrange */
        return A(...);
    }
 
//dans la classe fille :
 const [Type Classe Fille] operator-() const
    {
        /*tu définis le constructeur selon ce qui t'arrange */
        return [Type Classe Fille](...);
    }

~~renvoyer une copie ne marcherais pas puisque si on retournerais à chaque fois une instance de la classe mère et non une instance de la classe fille.~~

EDIT : le type de retour n'est pas pris en compte lors de la résolution du compilateur.

Bonjour,

la définition de l'opérateur - est

Code:

1
2
3
struct C {
 C operator-() const;
};

Puisqu'il s'agit d'un retour par valeur, l'héritage pose problème.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
struct C {
      int x;
      int y;
      C() : x(0), y(0) {}
      C(int _x, int _y) : x(_x), y(_y) {}
      C operator-() const { return C(-x, -y); }
      virtual void cout() const { std::cout<<"x:"<<x<<",y:"<<y<<std::endl; }
   };
   struct D : public C {
      int z;
      D() : C(0,0), z(0) {}
      D(int _x, int _y, int _z) : C(_x,_y), z(_z) {}
      D operator-() const { return D(-x, -y, -z); }
      virtual void cout() const { std::cout<<"x:"<<x<<",y:"<<y<<",z:"<<z<<std::endl; }
   };
 
   C* c = new D(1,2,3);
   c->cout();
   (-(*dynamic_cast<D*>(c))).cout();

Un peu indigeste, mais la seule solution amha.

Du coup, une solution plus propre serait

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
struct C {
      int x;
      int y;
      C() : x(0), y(0) {}
      C(int _x, int _y) : x(_x), y(_y) {}
      virtual void reverse(C*& _c) const { _c = new C(-x, -y); }
      virtual void cout() const { std::cout<<"x:"<<x<<",y:"<<y<<std::endl; }
   };
   struct D : public C {
      int z;
      D() : C(0,0), z(0) {}
      D(int _x, int _y, int _z) : C(_x,_y), z(_z) {}
      virtual void reverse(C*& _c) const { _c = new D(-x, -y, -z); }
      virtual void cout() const { std::cout<<"x:"<<x<<",y:"<<y<<",z:"<<z<<std::endl; }
   };
 
   C* c = new D(1,2,3);
   c->cout();
   C* c2;
   c->reverse(c2);
   c2->cout();

Il faudra juste avoir une attention aux fuites mémoires. Attention assez faible je pense puisque tu es déjà sur du pointeur/référence.

01/06/2012, 14h29
raf_gug

@Neckara, Bousk: merci pour vos réponses.
J'ai une question stupide: comment cela se passe pour la libération de la mémoire (puisque je fais un new explicite)? Du coup, je dois le faire manuellement, non? Et cela devient un code un peu délicat.

Y-a-t-il une solution standard dans ce genre de cas?
01/06/2012, 14h34
Bousk
Puisque tu as un new, tu dois avoir un delete.
Code:

1 2 3 4 5 6 7 8 C* c = new D(1,2,3); C* c2; c->reverse(c2); // do stuff with c2 // c2 now useless delete c2; // probably delete c; maybe elsewhere
Il y a peut-être un smart_pointer qui peut faire cela, aucune idée.
Mais il n'y a aucune difficulté à ça.
01/06/2012, 14h56
raf_gug

Parfait, merci!
01/06/2012, 20h32
Neckara
Je me pose tout de même une question :

Citation:

Puisqu'il s'agit d'un retour par valeur, l'héritage pose problème.

Est-ce vraiment le cas ? Comme le type de retour n'est pas pris en compte, toutes les méthodes ne se différenciant que par leur type de retours sont considérée comme étant une même et unique méthode (d'où des erreurs lors de la compilation).

Pourquoi ne pourrait-on pas mettre :
Code:

1 2 3 4 virtual C operator-() const { return C(-x, -y); } //et D operator-() const { return D(-x, -y, -z); }
Théoriquement ceci devrait fonctionner vu que le compilateur ne devrait pas tenir compte du code de retour lors de la résolution à moins que je ne me trompe ?

Je pense qu'il faudrait au maximum éviter de faire un new sans libérer soit-même avec un delete.

Et si tu ne passais pas par des méthodes mais par un ensemble de fonctions amies (pouvant éventuellement appeler des méthodes privées des membres)?
Code:

1 2 3 A operator-(const & A); D operator-(const & D);
Ainsi tu ne devrais plus avoir de problèmes (?)
04/06/2012, 11h26
Bousk

Fais le test et tu verras que jamais tu n'apelleras jamais D operator-(). Quand bien même C operator-() est virtual.
04/06/2012, 16h06
Neckara

En effet.

Il y a deux autres solutions possible il me semble :
- utiliser une fonction et non une méthode (je ne sais pas si ça marche)
- ne pas mettre d'héritage et mettre un template dans la fonction appelante.
04/06/2012, 16h33
koala01

Salut,

Il ne faut pas oublier une chose : l'opérateur - (tout comme n'importe quel opérateur de sémantique plus ou moins mathématique :D ) est, typiquement, un opérateur destiné à une classe ayant sémantique de valeur (parce qu'il provoquent, justement, une copie de l'objet et que la copie est incompatible avec une sémantique d'entité) !!!

Or, l'hértiage (public) est, au contraire, destiné à des classes ayant sémantique d'entité :aie:

J'aurais presque envie de dire que, de toute évidence, il y a une incompatibilité entre deux des besoins que tu sembles mettre en évidence :

D'un coté, tu voudrais que ta classe aie typiquement sémantique de valeur, alors que, de l'autre, tu voudrais profiter de l'héritage et donc avoir une classe ayant sémantique d'entité :aie:

Les bonnes questions à se poser semblent donc être :
Es tu sur que l'héritage est la solution la plus adaptée à ton problème :question:
Est-ce que l'héritage (public) que tu envisages respecte le sacro saint LSP (Liskov Substitution Principle) :question:
As tu plus besoin de l'opérateur ou de l'héritage (si tant est que LSP soit respecté) :question:
Est-ce que ton opérateur - est compatible avec la sémantique que tu voudrais lui donner :question: n'aurais tu pas plutot intérêt à créer une fonction nommée substract :question: quel devrait etre le résultat de cette focntion :question: créer un nouvel objet, ou modifier l'objet au départ duquel elle est invoquée :question:
04/06/2012, 16h43
raf_gug

Salut koala01,
Merci d'apporter un nouveau point de vue à cette discussion.

Mon but est de créer un certain ensemble de classes permettant de représenter des nombres (une pour des nombres rationnels, une pour des nombres complexes, une pour des éléments d'un corps finis à p éléments, ...). Du coup, je voulais créer une classe mère qui m'assurerait que toutes les classes enfant implémentent effectivement les différentes opérations dont j'ai besoin (surcharge d'opérateurs et 2-3 autres choses). La raison pour laquelle j'ai choisi de ne pas faire de templates et me diriger vers de l'héritage est que mes opérateurs sont trop spécifiques aux différentes classes enfants.

Aurais-je du faire différemment?

Merci!

Raf
04/06/2012, 18h52
koala01

Citation:

Envoyé par raf_gug

Salut koala01,
Merci d'apporter un nouveau point de vue à cette discussion.

De rien :ccool:

Citation:

Mon but est de créer un certain ensemble de classes permettant de représenter des nombres (une pour des nombres rationnels, une pour des nombres complexes, une pour des éléments d'un corps finis à p éléments, ...). Du coup, je voulais créer une classe mère qui m'assurerait que toutes les classes enfant implémentent effectivement les différentes opérations dont j'ai besoin (surcharge d'opérateurs et 2-3 autres choses). La raison pour laquelle j'ai choisi de ne pas faire de templates et me diriger vers de l'héritage est que mes opérateurs sont trop spécifiques aux différentes classes enfants.

Aurais-je du faire différemment?

Merci!

Raf

Justement, à partir du moment où l'on peut envisager le fait que tu ne commencera pas à mélanger des nombres rationnels avec des complex ou avec des entiers, c'est bel et bien vers les templates que tu devrais t'orienter :D

Autrement, cela signifie que tu envisages (par exemple, hein :D ) de pouvoir écrire monEntier - monComplexe, et obtenir quelque chose qui devrait se situer "quelque part" entre l'entier et le complexe or, cela n'a pas vraiment de sens :aie:

Tu peux, effectivement, envisager de le faire, mais ca devrait se gérer au niveau d'une classe proche de "opération" et mettrait sans doute en oeuvre un fonctionnement proche de celui de boost::any ;)

De plus, et je confirme là ce que j'ai dit plus haut, dés que l'on parle de valeur, on se trouve face à des objets ayant... sémantique de valeur, justement (dont, entre autres, il peut exister plusieurs instances identiques et comparable par égalité), et, il n'y a rien à faire : si une classe ayant sémantique d'entité peut ne pas intervenir dans une hiérarchie d'héritage, une classe ayant sémantique de valeur n'interviendra jamais dans une hiérarchie de classes ;)
05/06/2012, 10h26
oodini

Citation:

Envoyé par koala01

Or, l’héritage (public) est, au contraire, destiné à des classes ayant sémantique d'entité

J'aimerais bien que tu m'orientes vers des sources à ce sujet, car j'ai du mal à comprendre pourquoi.
05/06/2012, 18h39
Flob90

@oodini: Il faut bien voir que l'implication est dans le sens héritage publique => sémantique d'entité (*), et pas dans l'autre. Dit autrement, avoir une classe à sémantique d'entité n'est pas symptomatique d'un héritage publique.:ccool:

Le sens de cette implication ne vient pas tant du fait des classes à sémantique d'entité, mais de celles à sémantique de valeur qui elles sont incompatibles avec l'héritage publique

Plus exactement c'est l'héritage publique et la sémantique de copie qui sont incompatible avec la dualité valeur/entité.;)

En effet, une des différence entre les deux sémantiques est le caractère copiable :

-> Une entité ne peut être copiable, si une entité était copiable alors l'entité résultant et l'entité d'origine doivent être considérées comme identiques (c'est le sens d'une sémantique de copie), or deux entités différentes (au sens des objets) ne peuvent être identique (c'est le sens d'une sémantique d'entité).

->Une valeur est copiable, mais une valeur et sa copie résultante doivent être considérées comme identiques (bien qu'elles sont différentes au sens des objets), ceci se caractérise par les comportements de l'ensemble de l'interfaces qui doivent être invariables. Ce qui est incompatible avec l'héritage publique (l'héritage (**) est un moyen d'introduire un point de variation de l'interface et/ou de ses comportements (***), il n'a pas de raison d'être sinon).

NB: Ca ne reste que mon point de vue personnel ;)

(*) Cette implication héritage publique => sémantique d'entité reste quand même propre à la conception objets et à la dualité entité/valeur. Des besoins plus orienté technique que métier peuvent amener un héritage publique sans considerer cette dualité.

(**) Ici c'est général et ne s'applique pas qu'à l'héritage publique, dans le cas d'un héritage restrient (protégé ou privé) ce point de variation se retrouvé limité au sein de la hiérarchie, sans ce besoin alors un sous-objet membre est surment plus indiqué.

(***) Ici c'est général et ne s'applique pas qu'à la dualité entité/valeur, l'usage d'un héritage devrait toujours résulter d'un besoin d'introduire un point de variation dans l'interface et ses comportement.

Salut,
Citation:
Envoyé par Neckara
Pourquoi ne pourrait-on pas mettre :
Code:

1 2 3 4 virtual C operator-() const { return C(-x, -y); } //et D operator-() const { return D(-x, -y, -z); }
Soit tu masques si la fonction de la classe de base n'est pas virtuelle, soit tu dois avoir un retour co-variant de par la norme
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 struct base { base foo(); virtual base& bar(); virtual base error(); }; struct derived : base { int foo(); // masque la fonction de la classe de base et peut dès lors retourner n'importe quoi virtual derived& bar(); // OK derived& est un retour co-variant de base& virtual derived error(); // erreur derived n'est pas un retour co-variant de base };
Le retour covariant des fonctions virtuelles

Sinon pour tout ce qui est héritage, opérateur, sémantique de valeur/entité, 100% d'accord avec ce qui a été dit précédemment.
Rappel : F.A.Q. Quand est-ce qu'une classe a une sémantique de valeur ?
F.A.Q Quand est-ce qu'une classe a une sémantique de d'entité ?