Retour de fonction par référence?

Bonjour à tous.
Je suis à la recherche d'un job, et donc, je me retrouve confronté aux tests techniques, dont certaines questions feraient hurler nos compilateurs adorés.

L'une d'entre elles me tracasse particulièrement:

supposant une classe Complexe représentant un nombre complexe.

Citation:

---

Choisissez la meilleur implémentation de l'addition:

1. Complexe& operator+(Complexe const & a, Complexe const & b) {return Complexe(a.re+b.re, a.im+b.im);}
2. Complexe& operator+(Complexe const * a, Complexe const * b) {return Complexe(a->re+b->re, a->im+b->im);}
3. Complexe* operator+(Complexe const & a, Complexe const & b) {return new Complexe(a.re+b.re, a.im+b.im);}
4. Complexe* operator+(Complexe const * a, Complexe const * b) {return new Complexe(a->re+b->re, a->im+b->im);}

---

J'aurai personnellement définit:

Code:

---

1 2	Complexe operator+(Complexe const & a, Complexe const & b) {Complexe c(a); return c+=b;} Complexe& Complexe::operator+=(Complexe const& other) {re+=other.re; im+=other.im;}

---

ou encore, si on veut rester concis (mais il faut être friend...)

Code:

---

Complexe operator+(Complexe const & a, Complexe const & b) {return Complexe(a.re+b.re, a.im+b.im);}

---

Dans le même genre, une autre fois je trouve int& f(int a, int b) {return a+b;}Je croyais qu'on ne devait jamais retourner une référence sur une constante ou une temporaire…

Qu'en pensez-vous? Suis-je dans l'erreur?

Hello,

Citation:

---

Envoyé par leternel

J'aurai personnellement définit:

Code:

---

1 2	Complexe operator+(Complexe const & a, Complexe const & b) {Complexe c(a); return c+=b;} Complexe& Complexe::operator+=(Complexe const& other) {re+=other.re; im+=other.im;}

---

---

Pareil.

Parmis les 4 solutions proposées :

• la première et la deuxième retournent une ref sur un temporaire et sont donc fausses.
• La troisième et la quatrième génèrent des fuites mémoire si on fait pas attention et sont chiantes à utiliser.
• De plus la quatrième redéfini l'opérateur+ sur des pointeurs : à éviter.

S'il faut vraiment choisir dans cette liste, je prendrais la 3eme. Bien que ce soit un enfer à utiliser.

Code:

---

1 2 3

Complexe a, b, c; Complexe *d = *(a+b) + c; // (a+b) est perdu, ne peut pas être libéré. delete d;

---

Mais la seule solution valide est : std::complex.

Bonsoir,

tu as quelques erreurs de recopie dans les codes que tu présentes ;) trop de ; pas assez de , et ) par exemple^^

Sinon : http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

Les opérateur +-*/ ne peuvent pas retourner une référence ! (sauf cas super particulier/spécifique où l'opération modifierait un object déjà existant [pool, static ?] et le retournerait)
Retourner la référence d'un temporaire est interdit.
En sortie de fonction, la variable est détruite, et ta référence, fait référence à ... un joli paquet de bits qui vont joyeusement faire crasher ton application.:aie:
Remplace la référence par un pointeur, rajoute un & devant le type de retour, tu as exactement le même résultat, mais ça semble bien plus flagrant que c'est pas à faire je trouve. :aie:

Retourner un pointeur, "pourquoi pas", en tous cas rien ne l'interdit, sauf le bon sens à priori. :aie:
Ca compilerait surement, tant que tu n'essaye pas de chaîner des opérations (sinon, tu vas aussi devoir définir les opérateurs utilisant un pointeur sur le type en question - rappel : il est impossible de définir une opération entre 2 pointeurs).

M'est avis que si tu as trouvé ces 4 exemples sur des "tests" de boites, vaut mieux éviter la boite en question. En tous cas c'est ce que je ferais :roll:

Citation:

---

Envoyé par leternel

Qu'en pensez-vous?

---

J'ai toujours pensé que les tests comme les entretiens servaient autant à un candidat pour tester la boîte qu'à la boîte pour tester le candidat... :)

Citation:

---

Envoyé par Bousk

M'est avis que si tu as trouvé ces 4 exemples sur des "tests" de boites, vaut mieux éviter la boite en question. En tous cas c'est ce que je ferais :roll:

---

Peut-être que la boîte en question attendait comme réponse "aucune des 4", et attendait une proposition.
Il faut voir sous quelle forme se présentait la question (et la zone de réponse).

La question était explicitement un QCM, et effectivement, ils sont disqualifiés à mes yeux.

Vous me rassurez, j'avais fini par avoir un doute sur mes connaissances.
Il n'y a pas de prolongation de durée de vie par les références, donc pas de temporaires possibles.

Ça me rappelle mon prof de C qui, dans son spécial "cours de C++", nous avait présenté un "operator+" qui était en fait un opérateur +=...

Tu aurais pu leur signaler qu'ils avaient oublié bien évidemment les opérator + mélangeant en entrée des références et pointeurs et on aurait tout eu :mouarf:

Citation:

---

Envoyé par Boumbata

Tu aurais pu leur signaler qu'ils avaient oublié bien évidemment les opérator + mélangeant en entrée des références et pointeurs et on aurait tout eu :mouarf:

---

C'est parfaitement légal et utilisé http://www.cplusplus.com/reference/s...ing/operator+/
Sinon, je vois pas de quoi tu parles. :aie:

non mais oui je parlais de conserver les ref/pointeurs en sortie en intervertissant les entrées tststsss :mrgreen:

Citation:

---

Envoyé par leternel

L'une d'entre elles me tracasse particulièrement:

---

Il n'y a qu'une proposition qui compile (la 3), c'est donc la meilleure, mais si elle n'est pas bonne du tout.

Citation:

---

J'aurai personnellement définit:

Code:

---

1 2	Complexe operator+(Complexe const & a, Complexe const & b) {Complexe c(a); return c+=b;} Complexe& Complexe::operator+=(Complexe const& other) {re+=other.re; im+=other.im;}

---

ou encore, si on veut rester concis (mais il faut être friend...)

Code:

---

Complexe operator+(Complexe const & a, Complexe const & b) {return Complexe(a.re+b.re, a.im+b.im);}

---

---

Mon premier réflexe est d'implémenter les @= à partir des @, pas l'inverse qui se retrouve souvent piègeux (le a @= a qui ne fait pas ce qu'il faut est un classique).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Mon premier réflexe est d'implémenter les @= à partir des @, pas l'inverse qui se retrouve souvent piègeux (le a @= a qui ne fait pas ce qu'il faut est un classique).

---

Peux-tu développer là-dessus?

Edit: Ah non, je crois que je vois ce que tu veux dire. En gros, tu implémentes le @= à partir de @ et swap?

Je crois qu'il parle de ça

Code:

---

1 2 3 4 5

struct T { int a; T& operator+=(const T& _r) { a += _r.a; return *this; } T operator+(const T& _r) { r(*this); r += _r; return r; } };

---

Citation:

---

Envoyé par Médinoc

Edit: Ah non, je crois que je vois ce que tu veux dire. En gros, tu implémentes le @= à partir de @ et swap?

---

C'est mon premier réflexe. C'est moins piégeux que l'alias possible entre this et le paramètre.

Ah en effet, je n'y avais jamais pensé. J'y pensais pour l'opérateur= (jusqu'à ce que je découvre les joies du copy-and-swap), mais je n'avais jamais réalisé que les opérateurs @= étaient eux aussi exposés à de l'auto-affectation...

Bonjour,

Ceci :

Code:

---

1 2	Complexe& Complexe::operator+=(Complexe const& other) {re+=other.re; im+=other.im;}

---

devrait être :

Code:

---

1 2	Complexe& Complexe::operator+=(Complexe const& other) {re+=other.re; im+=other.im; return *this; }

---

Il n'y a pas de problème d'alias avec @=. La forme canonique (depuis un article de Koening je crois) pour l'implémentation des opérateurs, c'est celle donnée par leternel avec la correction de bretus

Code:

---

1 2	Complexe operator+(Complexe const & a, Complexe const & b) { Complexe c(a); return c+=b; } Complexe& Complexe::operator+=(Complexe const& other) { re+=other.re; im+=other.im; reutrn *this; }

---

Il y a une discussion, je ne sais plus où (peut être Sutter), sur l'opérateur +, qui peut être écrit selon 2 formes (de mémoire, la seconde est recommandée) :

Code:

---

1 2	Complexe operator+(Complexe const & a, Complexe const & b) { Complexe c(a); return c+=b; } // création d'un temporaire Complexe operator+(Complexe a, Complexe const & b) { return a+=b; } // passage par copie

---

Cf http://en.cppreference.com/w/cpp/language/operators (en particulier la partie Binary arithmetic operators)

@bousk
l'opérateur + ne doit pas être membre

Personnellement je ne recommande pas de faire `return a+=b`. Ça à la fâcheuse tendance de désactiver la RVO ou de faire un copy-ctor plutôt plutôt qu'un move-ctor. Il vaut mieux le faire en 2 étapes.

Je n'ai pas comprit l'histoire d'alias, c'est quoi ?

En gros, c'est un risque de problème quand tu fais a = a ou a += a.

Exemple volontairement exagéré:

Code:

---

1 2 3 4 5 6 7

MyString& MyString::operator+=(MyString const &right) { m_pchars = realloc(m_pchars, m_length + right.m_length +1); size_t oldLength = m_length; m_length += right.m_length; std::copy(right.m_pchars, right.m_pchars+right.m_length, m_pchars+oldLength);//oups! }

---

Citation:

---

Envoyé par mintho carmo

l'opérateur + ne doit pas être membre

---

Sauf si tu veux une opération dont l'ordre des opérandes importe (je sais plus le termr, la multiplication matricielle par exemple) / interdire un certain ordre

Citation:

---

Envoyé par mintho carmo

Il n'y a pas de problème d'alias avec @=.

---

Prends le cas de la multiplication de nombres complexes (et donc de *=) et tu verras le problème qu'évoque Jean-Marc

Citation:

---

Envoyé par mintho carmo

Il n'y a pas de problème d'alias avec @=.
La forme canonique (depuis un article de Koening je crois) pour l'implémentation des opérateurs, c'est celle donnée par leternel avec la correction de bretus

---

Tu me montres une multiplication de matrice implémentée comme ça et on regarde les allocations?

Citation:

---

Envoyé par Bousk

Sauf si tu veux une opération dont l'ordre des opérandes importe (je sais plus le termr, la multiplication matricielle par exemple) / interdire un certain ordre

---

Je ne vois pas de problèmes. J'ai systématiquement tous les opérateurs que je peux non membre.

Bon, ok, je n'aurais pas du être aussi affirmatif :D C'est en tout cas la forme qui est recommandé par plusieurs références

Je pensais à ça http://books.google.fr/books?id=Qx5o...page&q&f=false

Citation:

---

Envoyé par jo_link_noir

Personnellement je ne recommande pas de faire `return a+=b`. Ça à la fâcheuse tendance de désactiver la RVO ou de faire un copy-ctor plutôt plutôt qu'un move-ctor. Il vaut mieux le faire en 2 étapes.

---

Sans mettre en doute ce propos, il appelle franchement à une explication/un example/un lien (le lien fourni ne donne pas d'explication sur ce point).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Tu me montres une multiplication de matrice implémentée comme ça et on regarde les allocations?

---

C'est un peu tiré par les cheveux car la multiplication matricielle pour des matrices non-carrées ne peut pas être faite "sur place". L'operator*= ne devrait pas être implémenté. D'ailleurs il ne peut pas l'être si la matrice est templatée sur sa taille (cas fréquent pour les petites matrices). Pour une utilisation normale, non-suprenante (en place) de operator@= la déclaration de mintho carmo me semble tout à fait juste.

Citation:

---

Envoyé par user019

C'est un peu tiré par les cheveux car la multiplication matricielle pour des matrices non-carrées ne peut pas être faite "sur place". L'operator*= ne devrait pas être implémenté. D'ailleurs il ne peut pas l'être si la matrice est templatée sur sa taille (cas fréquent pour les petites matrices). Pour une utilisation normale, non-suprenante (en place) de operator@= la déclaration de mintho carmo me semble tout à fait juste.

---

Dans l'utilisation normale, on a besoin de l'ancienne valeur jusqu'au bout, ce n'est que dans des cas particuliers qu'il y a une séquence qui permette de modifier l'ancienne valeur sans la sauver en tout en en partie. Et encore plus particulier quand on peut composer l'ancienne valeur avec elle même... Une forme canonique doit fonctionner dans tous les cas, et pas être une optimisation parfois applicable.

Citation:

---

Envoyé par user019

C'est un peu tiré par les cheveux car la multiplication matricielle pour des matrices non-carrées ne peut pas être faite "sur place". L'operator*= ne devrait pas être implémenté. D'ailleurs il ne peut pas l'être si la matrice est templatée sur sa taille (cas fréquent pour les petites matrices). Pour une utilisation normale, non-suprenante (en place) de operator@= la déclaration de mintho carmo me semble tout à fait juste.

---

Comme tu le mentionnes, @= ne pose pas de problème sur les matrices carrées (et mine de rien ça couvre quand même pas mal de cas d'utilisation)
Et même sur les autres, tu as effectivement un blocage si tu représentes la matrice M*N par un tableau statique bidimensionnel de M*N. Mais il y a nombre de représentation où tu peux implémenter @= sans souci problème.

Maintenant, si l'exemple de multiplication de matrice te pose problème, prends la multiplication de nombres complexes, le souci est le même (même s'il est largement plus simple à résoudre).


Le point est que dans nombres de cas tu as des membres où modifications et utilisations se chevauchent.

Citation:

---

Envoyé par user019

Sans mettre en doute ce propos, il appelle franchement à une explication/un example/un lien (le lien fourni ne donne pas d'explication sur ce point).

---

Je suis désolé mais je n'ai pas de lien* expliquant bien ceci. Par contre, tu peux en déduire que la RVO s'applique sur les types non référencés et comme += retourne une référence elle ne s'applique pas ici.

* Juste un exemple (operator+ en 1 ligne, operator- en 2)

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 35 36 37

#include <iostream>   struct A { A() = default; A(const A&) { std::cout << "copy\n"; } A(A&&) { std::cout << "move\n"; } };   A& operator += (A& a, A const & b) { return a; }   A operator + (A a, A const & b) { return a += b ; }   A& operator -= (A& a, A const & b) { return a; }   A operator - (A a, A const & b) { a -= b ; return a; }   int main() { A a; A b; { std::cout << "--------\n"; A c = a+b; std::cout << "--------\n"; } { std::cout << "--------\n"; A c = a-b; std::cout << "--------\n"; } }

---

Citation:

---

--------
copy
copy
--------
--------
copy
move
--------

---

avec -fno-elide-constructors (pour désactivé la rvo)

Citation:

---

--------
copy
copy
move
--------
--------
copy
move
move
--------

---