Valeur renvoyée par un opérateur

Bonjour,

J'ai encore une question à propos de mes opérateurs surchargés :

Si je cherche à surcharger + dans une de mes classes, après avoir correctement surchargé +=, j'ai fait ceci :

Code:

---

1 2 3 4 5 6

template <typename Elem> PolyD<Elem>& PolyD<Elem>:: operator + (PolyD V) { V += (*this); return V; }

---

Ce qui fonctionne mais réflexion faite ça devrait planter royalement, vu que je renvois par référence un objet de portée locale, non ?
Je vais devenir fou avec ces opérateurs partout ...

merci

Effectivement, tu renvoie une référence vers quelque chose qui sera détruit au moment de quitter la fonction...

Ceci dit, assez bizarement, (en fait non: de manière très logique, si on suit la norme), si tu récupère la valeur de retour sous la forme d'une référence constante, cela fonctionnera sans problème, car une référence constante permet la construction d'un objet (qui deviendra temporaire pour la fonction dans laquelle tu récupère cette valeur)

A ce sujet, je te proposerais bien la lecture (en anglais) de cet article ;)

Ceci dit, l'opérateur += peut renvoyer une référence parce qu'il renvoie... l'objet modifié, alors que l'opérateur + seul renvoie normalement... un nouvel objet, qui n'est donc ni l'opérande de gauche (l'objet en "cours") ni celui de droite (qui est donné en paramètre), il ne devrait donc pas renvoyer une référence ;)

Ce qu'il faudrait normalement faire, c'est:

1. créer une variable du type ad-hoc qui soit la copie de l'objet en cours (*this)
2. utiliser (éventuellement) l'opérateur += sur cette variable en donnant comme opérande de droite l'objet passé en argument
3. renvoyer cette variable

Sur une classe MaClasse, l'opérateur se présenterait donc sous la forme de

Code:

---

1 2 3 4 5 6

MaClasse MaClasse::operator+(const MaClasse& op) const { MaClasse temp= *this; temp+=op; return temp; }

---

Nota: il n'est pas impossible que l'idiome copy and swap te vienne en aide pour une partie du travail ;)

Citation:

---

Ceci dit, assez bizarement, (en fait non: de manière très logique, si on suit la norme), si tu récupère la valeur de retour sous la forme d'une référence constante, cela fonctionnera sans problème, car une référence constante permet la construction d'un objet (qui deviendra temporaire pour la fonction dans laquelle tu récupère cette valeur)

---

On a eu cette discussion récemment avec un ami, et j'avoue que je veux bien une clarification là-dessus. Le code suivant est valide de manière incontestable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

A f() { A a; return a; }   int main() { const A& localA = f(); ... }

---

Par contre, le code suivant fait planter gcc à l'utilisation de localA

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

const A& f() { A a; return a; }   int main() { const A& localA = f(); ... }

---

En fait, le problème qu'on voit, c'est que autant, dans le cas de la valeur de retour, le compilateur sait statiquement où elle est allouée, et peut donc sans problème augmenter sa durée de vie, autant, dans le cas d'un renvoi de référence d'un objet alloué sur la pile en train d'être détruite, ce ne peut être fait que dynamiquement. Mais pourtant, ne pas le faire rompt le fait que la durée de vie d'un objet est étendu à celle de la référence constante...

Donc, bug de gcc ou incompréhension de la norme de ma part ?

Le coup de la référence constante sur la valeur de retour, c'est un "truc" du langage.
Mais il n'y a pas de "truc" pour les fonctions qui retournent directement une référence.

Diable, comment ais-je fait mon compte pour ne pas me rendre compte que le code adapté était simplement :

Code:

---

1 2 3 4 5 6 7

MaClasse MaClasse::operator+(const MaClasse& op) const { MaClasse temp= *this; temp+=op; return temp; }

---

Je m'obstinais à vouloir renvoyer une référence 8O

Cela m'étonne toujours que mon code fonctionnait cependant, je vais essayer de lire ton article koala01

Merci infiniment à tous (plus particulièrement à koala01 qui me tire d'embarras depuis quelques jours déja ;) )

Citation:

---

Envoyé par Opérateur

Diable, comment ai-je fait mon compte pour ne pas me rendre compte que le code adapté était simplement :

Code:

---

1 2 3 4 5 6 7

MaClasse MaClasse::operator+(const MaClasse& op) const { MaClasse temp= *this; temp+=op; return temp; }

---

---

Ou plutôt :

Code:

---

1 2 3 4 5 6 7

const MaClasse MaClasse::operator+(const MaClasse& op) const { MaClasse temp(*this); temp+=op; return temp; }

---

Il faut toujours utiliser le constructeur de copie, plutôt que la combinaison constructeur par défaut + affectation. Et il est préférable de (c'est à dire, il faut, sauf bonne raison de ne pas le faire (il y en a)) renvoyer un objet constant puisque c'est un temporaire.

Citation:

---

Le coup de la référence constante sur la valeur de retour, c'est un "truc" du langage.
Mais il n'y a pas de "truc" pour les fonctions qui retournent directement une référence.

---

En fait, la norme étant un peu chère pour quelqu'un qui n'en a pas besoin, je ne sais pas ce qu'elle dit exactement à ce propos. De ce que j'en comprenais, le "truc" était plus une conséquence heureuse d'un bout de la norme, pas que c'était un choix délibéré de départ. Est-ce bien un choix délibéré, qui concerne uniquement les références constantes sur les valeurs de retour d'une fonction, dans le corps de l'appelant ?

Citation:

---

Envoyé par white_tentacle

En fait, la norme étant un peu chère pour quelqu'un qui n'en a pas besoin, je ne sais pas ce qu'elle dit exactement à ce propos. De ce que j'en comprenais, le "truc" était plus une conséquence heureuse d'un bout de la norme, pas que c'était un choix délibéré de départ. Est-ce bien un choix délibéré, qui concerne uniquement les références constantes sur les valeurs de retour d'une fonction, dans le corps de l'appelant ?

---

Si j'en croit l'article proposé par Koala, c'est dans la norme :

Citation:

---

Normally, a temporary object lasts only until the end of the full expression in which it appears. However, C++ deliberately specifies that binding a temporary object to a reference to const on the stack lengthens the lifetime of the temporary to the lifetime of the reference itself, and thus avoids what would otherwise be a common dangling-reference error. In the example above, the temporary returned by f() lives until the closing curly brace. (Note this only applies to stack-based references. It doesn't work for references that are members of objects.)

---

Citation:

---

Si j'en croit l'article proposé par Koala, c'est dans la norme :
...

---

C'est justement le coeur du problème, est-ce vraiment ce que dit la norme ?

Parce que sinon, le code suivant

Code:

---

1 2 3 4 5 6 7 8 9 10 11

const A& f() { A a; return a; }   int main() { const A& localA = f(); ... }

---

devrait être valide... En effet, on renvoie un temporaire, dont on étend la durée de vie au moyen de l'affectation à une référence constante (le retour de la fonction), qui fait qu'il est encore valide dans l'expression const A& localA = f(), et on étend encore sa durée de vie dans main.

Pourtant, ça plante dans gcc (je n'ai rien d'autre sous la main pour tester). Quelle subtilité j'ai raté ?

a n'est pas un "temporaire", c'est une variable. Sa durée de vie est fixée.
Il n'y a pas de temporaire si c'est une référence qu'on retourne.

Citation:

---

a n'est pas un "temporaire", c'est une variable. Sa durée de vie est fixée.
Il n'y a pas de temporaire si c'est une référence qu'on retourne.

---

Même dans le cas suivant ?

Code:

---

1 2 3 4

const A& f() { return A(); }

---

Il y a bien un temporaire.

Cela dit, je viens de faire deux trois tests, et je pense avoir trouvé l'élément qui me manquait.

Ce qui marche, c'est ça :

Code:

---

const A& var = f();

---

ce qui ne marche pas, c'est ça :

Code:

---

const A& var = static_cast<const A&>(f());

---

Lorsqu'on renvoie une référence vers A(), ce n'est pas une affectation, mais un cast. Donc, ça ne fonctionne pas, et c'est cohérent.

Citation:

---

Envoyé par white_tentacle

Il faut toujours utiliser le constructeur de copie, plutôt que la combinaison constructeur par défaut + affectation.

---

Code:

---

1 2 3

MaClasse a; MaClasse b = a;

---

est un appel au constructeur par copie, ce n'est pas un appel au constructeur par défaut suivi d'un appel à l'opérateur d'affectation. C'est strictement identique à

Code:

---

1 2 3

MaClasse a; MaClasse b(a);

---

Sinon, une différence que je vois entre

Code:

---

const A val(){...}

---

et

Code:

---

const A& ref(){...}

---

c'est qu'avec la première, on est certain que l'objet que l'on obtient est une copie anonyme, temporaire et inutilisée autre-part de la valeur de retour de la fonction, a priori la référence peut la récupérer sans risque en étendant sa durée de vie. Alors qu'avec la seconde, il est impossible de savoir d'où vient réellement la valeur de retour, à laquelle il peut arriver toutes sortes de choses. Typiquement :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <iostream>   class A { public: int x; A():x(0) {} };   const A& ref(const A& a){ return a; }   int main(){   A* pa = new A; const A &a = ref(*pa); delete pa; std::cout << a.x << std::endl; return 0; }

---

Ceci-dit, ce code compile (et s'exécute ??!!) sous visual...

J'ai une dernière question si vous permettez.

Dans une de mes classes polyS (qui hérite d'une classe vecteur) je redéfinis l'opérateur unaire - ainsi :

Code:

---

1 2	PolyS& operator - ();

---

et de même dans ma classe vecteur j'ai :

Code:

---

1 2	virtual Vecteur& operator - ();

---

Cependant réflexion faite je ne voyais pas l'interêt d'aller renvoyer une référence.
J'ai donc plutôt changé cela en :

Code:

---

1 2	PolyS operator - ();

---

et

Code:

---

1 2	virtual Vecteur operator - ();

---

Et ça ne passe pas à la compilation, il me dit qu'il y a une incompatibilité de types covariants ou je ne sais quoi.
D'où cela peut-il bien provenir ?

merci :-)

Un retour covariant c'est lorsque une méthode d'une classe fille redéfinit une méthode de la classe mère mais en ne respectant pas totalement le protoype de la méthode redéfinie et en ayant une valeur de retour d'un type dérivé du type originel. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

class Clonable{ public: virtual Clonable& clone() const = 0; };   class Impl : public Clonable{ public: virtual Impl& clone() const; //retour covariant };

---

C'est expliqué plus en détail dans la faq.

Je suppose que dans le cas d'un pointeur ou d'une référence le compilateur tolère les retour covariant, mais pas dans le cas des valeurs. Par curiosité, quel compilateur utilises-tu ?


Sinon, pourquoi penses-tu que ton opérateur devrait renvoyer une valeur ? Est-il illogique que l'on puisse appliquer une autre fonction ou un autre opérateur ? Par exemple :

Code:

---

1 2 3

int i = 0; ++(++i);

---

Ceci incrémente 2 fois la variable i, et c'est ce qui en est attendu. Cela pose-t-il problème dans ton cas ?

Effectivement, le retour co-variant doit s'appliquer sur une référence ou sur un pointeur ;)

Il est à noter que l'on ne parle de retour co-variant que sur des méthodes virtuelles, mais qu'une situation proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class A { /*...*/ }; class B: public A { /*...*/ }; class Base { public: virtual A& foo(); } class Derivee : public Base { public: virtual B& foo(); }

---

entraine également le retour co-variant (il n'y a aucun lien requis entre la classe qui contient la méthode et le type qui est renvoyé, mais les types renvoyés doivent faire partie d'une même "arborescence")

Il faut aussi savoir que, si tu déclares une méthode virtuelle dans la classe de base, la méthode reste virtuelle dans la classe dérivée, même si tu ne le précise pas explicitement.

Le résultat est que le compilateur considère que cette méthode surchargée met en oeuvre un retour co-variant, si la valeur de retour n'est pas la même dans la classe de base que dans la classe dérivée.

Dans ton cas, il ne s'agit donc pas de trouver le moyen de faire effectuer un retour co-variant de manière correcte (en renvoyant, par exemple une référence) mais bien de rendre la méthode non virutelle (en supprimant le mot clé virtual de la déclaration dans la méthode de la classe de base) car, si tu travailles avec une instance de classe vecteur, le retour de méthode doit bel et bien être... une nouvelle instance de vecteur et non une nouvelle instance de PolyS ;)

Note: C'est peut-être un peu hors-sujet, mais je vois mal une méthode Clone() retourner une référence plutôt qu'un pointeur...

Me revoilà, désolé pour le retard de ma réponse j'avais un peu perdu le topic de vue ;)

Ok je pense que je comprend mieux. Je n'ai de toute façon pas besoin de déclarer les opérateurs virtuels dans la classe de base, effectivement, je suis idiot :mrgreen:

Ca règle donc le problème.
J'utilise DevC++, donc le compilateur c'est gcc si je me souviens bien.

merci beaucoup à tous ;) !