Discussion :

[cyberjoac]

Bonjour a tous, me revoila a la charge pour de nouvelles questions de type theorique sur la surcharge d'operateurs en C++.
C'est pas passionnant mais bon c'est un passage oblige pour bien comprendre la logique des programmes complexes!
Ci-dessous des extraits de questions recommandees par l'universite pour une etude autonome du C++:

1/ Nous avons une classe Complex qui represente des nombres complexes (x+iy) et on surcharge l'operateur "-" de la facon suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
const Complex operator-() const {
     return Complex(-_re , -_im);
}

On me propose deux autres implementations, et on me demande leurs defauts par rapport a la 1ere:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
const Complex& operator-() const {      
    _re = -_re;
    _im = -_im;
    return *this;
}
 
const Complex& operator-() const {
    Complex* c_ptr = new Complex(-_re, -_im);
    return *c_ptr;
}

2/ On implemente l'operateur + comme une fonction friend :
friend const Complex operator+ (const Complex &c1, const Complex &c2);
Pourquoi la definition de cette fonction comme fonction membre (et non pas friend) aurait echoue? (const Complex operator+(const Complex &c);
Si possible donner un exemple...

3/ On propose une autre implementation de l'operateur "-" comme fonction globale friend:
friend const Complex operator-(const Complex &c)
Est-ce que ce code passera sans probleme?

4/ Expliquer pourquoi il est preferable d'utiliser : c1 *= c2 au lieu de c1 = c1*c2; (c1, c2 de type Complex).

=====================================================================
On decide maintenant d'implementer notre propre classe d'objets string (MyString) qui comprend
- pointeur vers char (char*)
- size
- memoire pour le tableau de char est alloue dynamiquement.

Les questions sont les suivantes:
1/ Doit on obligatoirement implementer par nous meme un operateur de copie (operator=) ou peut on se contenter de l'operateur par defaut?

2/ Supposons que l'on veuille implementer l'operator= de la facon suivante:
MyString& operator=(const MyString &n1)
Cet operateur effectue un delete de la memoire deja alloue et alloue de la memoire pour le nouveau tableau de chars, met a jour le size.
Expliquez quel est le probleme pose par le code suivant:
MyString n1("my string");
n1 = n1;
Proposez un moyen de corriger ce probleme.


Merci beaucoup d'avance pour toute aide...

[Médinoc]

Je suis de bonne humeur ce matin:

1. Les défauts de ces deux implémentations:
   
   1. Ne compilera pas, car brise la const-correctness.
   2. Retourne une référence vers un objet alloué sur le tas. Quand on joue avec le tas, mieux vaut rester explicite jusqu'au bout et retourner un pointeur (ce qui est impossible ici). Cette fonction est une usine à fuites de mémoire.
2. C'est l'opérateur + unaire ou binaire ?
3. Je ne sais pas.
4. L'opérateur *= ne nécessite aucune construction ni appel à l'opérateur d'affectation, dandis que le =c1*c2 exige la construction d'un résultat intermédiaire et l'affectation dans c1.

[Médinoc]

1. Oui. Affectation ET constructeur de copie.
2. Le delete supprimera la mémoire en cas d'auto-affectation. Le mieux est de détecter l'auto-affectation et de ne rien faire dans ce cas-là.

[cyberjoac]

Merci beaucoup pour tes reponses precises ca m'aide vraiment beaucoup!!!
Pour ce qui est de la question 2/ il s'agit bien de l'operateur + binaire.

Merci encore!

[zais_ethael]

2. Je ne vois pas en quoi cela poserait problème, la seule utilité en utilisant une fonction externe (qui n'est pas obligatoirement friend d'ailleurs) est d'étendre les opérateurs d'une classe que tu ne peux modifier. C'est utile par exemple pour étendre ostream et istream, mais la ça ne sert à rien. Edit: Ha si, il y a le fait que cette méthode n'est pas const.
3. A priori oui, mais en même temps on défini rarement un opérateur unaire à l'extérieur de la classe Faudrait tester pour être sur.

Soit dit en passant, je ne comprend pas pourquoi ton prof renvoie des const Complex partout, à partir du moment où c'est une copie c'est plus utile en non-const.

[Mat007]

Salut,

Soit dit en passant, je ne comprend pas pourquoi ton prof renvoie des const Complex partout, à partir du moment où c'est une copie c'est plus utile en non-const.

C'est pour éviter de se servir de la valeur de retour en tant que l-value modifiable par mégarde, voir par exemple le point (4) dans le GotW #6.

MAT.

[Luc Hermitte]

Je crois que Sutter en parle dans XC++ (-> GOTW pour ceux qui n'ont pas le bouquin), il y a deux écoles à ce sujet.
Cela permet de ne pas enchainer des mutations sur les résultats temporaires non encore nommés.