Surcharge d'opérateur << pour un ostream

Bonjour à tous,

Je débute en C++ et j'ai une question concernant la surcharge d'opérateurs de flux. Je comprends ce que font les lignes suivantes mais j'ai deux questions:

Code:

---

1 2 3 4 5

ostream& operator<<(ostream& out, A& x ) { out << x.y << endl; return out; }

---

la première: Pourquoi renvoit-on une référence sur un object ostream?
la deuxième: Pourquoi met-on un object ostream "out" en argument pour le modifier et le renvoyer? pour moi mettre un paramètre en argument ça sert d'input. Pourquoi on écrit tout simplement pas:

Code:

---

1 2 3 4 5 6

ostream& operator<<( A& x ) { ostream& out; out << x.y << endl; return out; }

---

Merci de votre aide!!!

Salut,

Ce qu'il se passe, c'est que l'opérateur << est prévu pour pouvoir être "chainé".

En effet, tu peux décider d'écrire (j'utilise cout comme flux dans l'exemple, mais il en va de même pour tous les autres ) quelque chose comme

Code:

---

1 2 3 4 5 6 7 8

int i, j, k; std::cout<<i; std::cout<<" "; std::cout<<j; std::cout<<" "; std::cout<<k; std::cout<<"\n";

---

mais tu te retrouve à écrire cinq fois std::cout alors que tu pourrais parfaitement réduire l'écriture en

Code:

---

1 2	int i,j,k; std::cout<<i<<" "<<j<<" "<<k<<"\n";

---

Ca, c'est ce que l'on appelle le "chainage d'appels".

Pour que cela puisse fonctionner, il faut que la fonction que tu appelle renvoie une référence vers l'objet courant. On en arrive donc à une situation dans laquelle :

1. il faut fournir l'ostream en paramètre sous forme d'une référence pour que la fonction (en fait, l'opérateur dans le cas présent) puisse connaitre le flux
2. il faut que l'opérateur renvoie le flux qu'il a reçu pour permettre le chainage d'appels

Il faut en outre savoir

1. que les flux d'entrée et de sortie ne sont pas copiables. On ne peut donc pas les transmettre par valeur (ce qui obligerait de les copier) comme argument
2. le code ostream & os a pour effet de déclarer une référence. Or, une référence doit etre initialisée lors de la déclaration avec l'objet qui sera référencé

C'est pour ces deux raisons que le code que tu proposes (et que je remet ici):

Code:

---

1 2 3 4 5 6

ostream& operator<<( A& x ) { ostream& out; out << x.y << endl; return out; }

---

sera purement et simplement refusé à la compilation.

Je rajoute d'autres détails à cette riche explication.

un opérateur est une fonction quasiment comme une autre, seule sa signature est particulière.

tout opérateur op binaire (au sens ayant deux opérandes) s'utilise a op b et se définit de l'une des deux façons suivantes:

Code:

---

1 2 3 4 5

//par une fonction libre <type retour> operator op (<type de a> a, <type de b> b);   //par une fonction membre <type retour> <type de a>::operator op (<type de b> b) <const ?>;

---

Pour ostream << truc, c'est défini par une fonction libre parce qu'on ne peut pas modifier la classe ostream. (entre autres raisons)

Comme l'a dit koala01, on veut pouvoir chainer l'appel, donc le type de retour est celui du premier argument, qu'on retournera.

Comme le stream est modifié par la fonction (il contient plus de texte), il ne peut pas être une référence constante
Ne reste que la variable ou la référence modifiable. On préfère cette dernière pour deux raisons:

• on ne veut pas copier le stream, potentiellement gros,
• on ne peut pas le faire, car le stream est une entité, non copiable par essence

Du coup, ne reste effectivement qu'une seule syntaxe générale:

Code:

---

1 2 3

std::ostream& operator << (std::ostream& os, <type de ton choix> <const & ?> bidule) { return os; }

---

La plupart du temps, on peut même profiter du chainage pour ramener le corps à une seule ligne:

Code:

---

1 2 3

std::ostream& operator << (std::ostream& os, triplet const & bidule) { return os << bidule.first<< ' '<< bidule.second<< ' '<< bidule.third; }

---

La référence constante sur bidule est souvent préférable.
En fait, j'estime que la référence constante devrait être la sémantique par défaut, et qu'on ne devrait avoir à spécifier que les références volatiles et les non références

Citation:

---

Envoyé par jasonbecker

Code:

---

1 2 3 4 5

ostream& operator<<(ostream& out, A& x ) { out << x.y << endl; return out; }

---

la première: Pourquoi renvoit-on une référence sur un object ostream?
la deuxième: Pourquoi met-on un object ostream "out" en argument pour le modifier et le renvoyer?

---

Comme l'ont dit d'autres c'est pour pouvoir "chaîner" les appels à operator << () :

Code:

---

1 2 3

a << b << c; // Equivalent à (a << b) << c;

---

L'expression (a << b) est traduite implicitement en (operator<< (a, b)), qui est comme l'a dit l'eternel une fonction comme une autre.
Donc si cette dernière renvoie un ostream&, (a << b) est un ostream& et on peut donc faire (a << b) << c.

Ensuite, si tu prends un code concret :

Code:

---

1 2 3 4 5

std::cout << "Toto" << 42 << std::endl; // Equivalent à ((std::cout << "Toto") << 42) << std::endl; // Equivalent à ((operator<< (std::cout, "Toto")) << 42) << std::endl;

---

std::cout est le premier paramètre passé à operator<< (), c'est pourquoi le premier paramètre est de type ostream&. Tu ne peux pas instancier un ostream, la classe étant abstraite, par contre tu peux récupérer une référence sur une instance d'une classe dérivée. Cette instance pourrait être n'importe quel flux de sortie : un fichier, une connexion réseau, un buffer ... Ici, tu veux écrire sur la sortie standard, c'est pourquoi tu précises "std::cout", en le passant par référence, pour la raison citée précédemment.

Merci beaucoup pour ces riches explications!!! J'aurais jamais vu le truc.

Tès bonne journée à tous
J'aime ce forum!!

Le même principe est parfois utilisé pour les setters de certains objets, sur certaines plate-formes (pas forcément en C++, possiblement en d'autres langages orientés objet):

Code:

---

1 2 3 4 5 6 7 8 9 10

class A { private: int b, c, d; public: A& setB(int newB) { b=newB; return *this; } A& setC(int newC) { c=newC; return *this; } A& setD(int newD) { d=newD; return *this; } };   A a; a.setB(1).setC(42).setD(3);

---

Le chaînage des << correspond un peu au même schéma, mais avec des opérateurs binaires plutôt que des fonctions membres.

Par contre, cette pratique n'est pas recommandée, ne serait-ce parce qu'une classe exposant directement son contenu par des getters et setters n'est pas recommandée.

C'est super pratique pour les classes de config !