Surcharge d'opérateurs de flux

Je cherche à comprendre pourquoi la documentation que j'ai consulté sur le net semble unanime pour proposer en matière de surcharge de l'opérateur de flux >> une fonction externe à la classe, déclarée amie dans la classe et ayant le prototype suivant :

Code:

---

istream& operator>>(istream& flux, Objet& unObjet) ;

---

J'ai fait un petit exercice avec une classe "nombres complexes" ultra simple : deux attributs privés "double" pour les parties réelles et imaginaires et un constructeur avec deux paramètres double pour initialiser l'objet "nombre complexe".
Puis pour entrer au clavier un nombre complexe dans le main.cpp, j'ai surchargé l'opérateur >> de 3 façons différentes :
La façon classique :

Code:

---

1 2 3 4 5 6 7 8

istream& operator>>(istream& flux, Complexe& a) { cout<<"partie reelle ? "<< endl ; flux>>a.m_r ; cout<<"partie imaginaire ?" << endl ; flux>>a.m_i ; return flux ; }

---

avec dans le fichier complexe.h la déclaration d'amitié classique :

Code:

---

friend std::istream& operator>>(std::istream& flux, Complexe&) ;

---

Cela marche très bien ... et ne m'étonne pas puisque je me conforme en tout point à ce que tous les auteurs recommandent.
Mais ce qui m'étonne un peu plus, c'est que les deux autres façons de surcharger l'opérateur >>, qui suivent marchent tout aussi bien et me semblent tout aussi logiques. Les voici :

Code:

---

1 2 3 4 5 6 7 8

Complexe& operator>>(istream& flux, Complexe& a) // { cout<<"partie reelle ? "<< endl ; flux>>a.m_r ; cout<<"partie imaginaire ?" << endl ; flux>>a.m_i ; return a ; }

---

avec dans le complexe.h la déclaration d'amitié suivante :

Code:

---

friend Complexe& operator>>(std::istream& flux, Complexe&) ;

---

et la deuxième qui marche tout autant :

Code:

---

1 2 3 4 5 6 7

void operator>>(istream& flux, Complexe& a) { cout<<"partie reelle ? "<< endl ; flux>>a.m_r ; cout<<"partie imaginaire ?" << endl ; flux>>a.m_i ; }

---

avec dans le complex.h la déclaration d'amitié suivante :

Code:

---

friend void operator>>(std::istream& flux, Complexe&) ;

---

Ma question est donc : Pourquoi la première solution serait la meilleure ?
Merci à tous
JMC55

Normalement le mieux pour ton opérateur >> c'est surtout de retourner lui-même pour pouvoir chaîner les appels. En retournant un Complexe& ou void tu empêches cette syntaxe des plus sexyes :)
Quant à savoir pourquoi l'un ou l'autre est mieux.. amha ça tient de la préférence personnelle.
L'avantage avec un opérateur externe, c'est que tu peux l'ajouter à ta classe sans avoir à la modifier, sans avoir à y ajouter une fonction membre, ce qui est parfois impossible justement. Et il me semble que C++17 prépare quelque chose en ce sens justement. Mais pas de quoi fouetter un débutant :)
Mais si tu dois le déclarer friend, aucun intérêt donc.

Merci beaucoup pour votre réponse rapide. J'ai compris que le chainage de l'opérateur de flux >> n'est possible que si la valeur de retour est du type référence sur un istream (on peut faire le même constat avec ostream). Un bon apprentissage nécessite beaucoup d'expérimentations !!!! Merci encore
JMC55

Pourtant contrairement à Bousk, je n'avais pas compris comme cela :wow:

Il y a les opérateurs qu'on est obligé de mettre en membre à cause du compilateur: operator=, operator[], operator*, operator&, operator-> ...

Ensuite cela va dépendre si dans la fonction amie, le premier paramètre (le plus à gauche) est un type que l'on peut modifier (ou un type simple).

Si oui, alors soit une méthode soit une fonction amie. Mais pour les opérateurs qui ne modifie pas le this, on préfère la fonction amie pour ne pas surcharger la classe.

Sinon, comme les streams istream, on préfère la fonction amie pour des histoires de conversions.

Personnellement, j'éviterais de faire une surcharge de operator>> qui soit interactive: Si je veux une fonction qui demande à l'utilisateur les données plutôt que lire en silence, j'en fais une vraie fonction, et non une surcharge d'opérateur.

Je partage tout à fait la remarque de Médinoc. Mon propos initial était didactique : envisager toutes les façons de concevoir une surcharge d'opérateurs de flux, même les plus "non conventionnelles" mais il est assez évident que dans un développement professionnel il vaut mieux éviter de surcharger l'opérateur >>. Merci encore pour vos remarques.