Bonjour !


Je me posais une question sur l'objet ostream, comment fait il pour faire plusieurs chaîne de suite avec un opérateur (/méthode) ?

Par exemple, imaginons que je créer une classe "print_string", et qu'elle contienne cette méthode : operator<<(string chaine);



je peut donc faire dans la fonction principal :



tout comme je peu faire avec cout :



Mais là où je bloque, c'est quand je veux faire ça :


Mais cela ne fonctionne pas évidemment car cela équivaut à faire :



Alors la question que je me pose est : quel est donc la méthode de l'operateur << de l'objet ostream qui permet bien d'afficher plusieurs chaîne à la suite ?

Bonjour

Je ne connais pas le procédé qu'utilise cout et autre flux, mais s'il fait comme je pense ta technique ne marchera jamais.

A mon avis si tu fait cout << "blabla" blabla va être appendue à la fin du flux. Donc pas affiché directement.

Enfin p'têtre que je me plante bien profond dans mon résonnement ...

Hiura

Une fonction de flot doit toujours être défnie comme fonction libre car son 1er argument doit être une réfernce sur un ostream(ou istream).
Pourquoi libre ?
Car le 1er argument d'une fonction membre d'une classe est le pointeur this.

Ensuite pour gérer ce que tu décrit , c'est comme pour l'opérateur d'affectation , il renvoit une référence sur le flux.

Le patron d'une classe xstream est alors :

Mmmh, je dirais plutôt qqch comme:



Il vaut mieux utiliser une référence constante pour éviter une copie inutile.

La déclaraton d'amitié est recomandé mais non obligatoire.
En effet , on peut créer un conglomérat de variable (une structure par défault) et voir besoin de définir les opérateurs de flux .
Dans ce cas , l'amitié est facultative puisque tout est publique.

Cf le post de Nanoc pour la bonne signature.
Au détail de l'amitié qui n'est pas une fatalité ici -- je n'irai pas jusqu'à dire recommandée. Il suffit que la classe fournisse accesseurs (/resp. constructeur d'initialisation) pour définir l'opérateur d'insertion (/resp d'extraction)

Citation : lmghs

Cf le post de Nanoc pour la bonne signature.
Au détail de l'amitié qui n'est pas une fatalité ici -- je n'irai pas jusqu'à dire recommandée. Il suffit que la classe fournisse accesseurs (/resp. constructeur d'initialisation) pour définir l'opérateur d'insertion (/resp d'extraction)

J'avais crue mettre une référence pourtant elle est pas là.
Sinon , les accesseurs , à moins de les rendres inlines , ne vont t'il pas ralentir le programmme ?
Car s'il y a beaucoup de variables à gérer, ca fait 2 sauts par accesseurs( un call , puis un ret)

T'inquiête, une manipulation de flux coûte bien plus cher qu'un passage via un accesseur -- et c'est encore pire quand c'est pour finir sur l'écran ou dans un fichier.

Heu, j'ai pas tout compris là, voir pas du tout !

imaginons en faite que je veille reprogrammer une class ostream, comment devrais-je faire pour afficher des chaines de caractère avec operator<< ?

Citation : mghs

c'est encore pire quand c'est pour finir sur l'écran ou dans un fichier.

ostream ne peut de toute facon viser que l'ecran ou un fichier ?
Ou peut il viser autres chose ?
Si oui , je ne vois pas quoi.

Tu as aussi les flux pour envoyer sur un réseau, ou même tout simplement sur une string, ça existe...

Sinon, "le premier argument d'une méthode c'est le pointeur this" ce n'est valable que pour les opérateurs, et encore que les opérateurs post-fixés...

À part ça, les flux donnent leurs ordre à l'écran via d'autres mécanismes qu'un simple printf(), si tu veux tu peux fouiller dans les sources des bibliothèques C++ de GCC pour t'en donner une idée, mais bonne chance pour comprendre...

Si tu veux définir ton type de flux, ne vas pas dériver std::ostream, mais std::streambuf. Cf la FAQ de fclc++.

Hum, bon, à ce que je vois ça a l'air assez compliqué ! Je ne m'y attendais pas !

Oui la mécanique interne des stream est relativement complexe. Mais en réalité on s'enfout. C'est le principe de l'encapsulation. Tu n'as pas besoin de savoir comment fonctionne chaque pièce de ta voiture pour pouvoir rouler avec.