Reprise du message précédent :
J'aurais préféré un exemple que l'on programme soit meme, pas la SL.  
Mais justement, tu vas peut être éclairer ma lanterne sur ce sujet.
Je trouve pas normal que istream définisse tellg/seekg, et ostream tellp/seekp. Les 2 devraient définir tell et seek. Quel est le sens à avoir une fonction qui permet de manipuler explicitement le get pointeur dans une classe ou il n'y a que ce pointeur, et pareillement avec le put pointeur de ostream. Dans les 2 cas on s'attendrais à manipuler le seul pointeur existant. En bref, selon moi, le fait qu'il y ait tellg sous entend qu'il y a tellp, et il ne devrait y avoir du coup que tell.
Mais ça c'est a cause de l'héritage multiple de iostream justement, où on serait bien emmerdé avec ces 2 fonctions en double. Donc pour moi ici l'héritage multiple n'est pas élégant du tout. Je trouve l'approche de .Net meilleure où on a dissocié le stream de ses opérations. Tu as System.IO.Stream d'un côté, et System.IO.StreamWriter et System.IO.StreamReader de l'autre.
En somme c'est un peu streambuf et ostream/istream.

ah bon ? moi je suis très content qu'il y ait 2 pointeurs différents, on peut imaginer des implémentations qui maintiennent 2 buffers.
 
moi je m'en fout : le fait est qu'en Java ou autre, je me suis souvent fait couilloner. Y a  des API qui t'obliges à hériter de que quelque chose, genre un MachinObject, toi quand tu te pointes, avec ta sauce déjo faite, t'es bien baisé, tu réutilises quedal, tu recode tout en composition et tu te ranges ton polymorphisme au cul

moi je me penche sur C# parcequ'on ma dit que l'eleet fait du C#.
 
Et plus sérieusement parce que je me penche sur à peu près tous les langages qui passent.

Tu n'as pas compris ma remarque. Ce que tu dis est évident pour iostream. Mais pour istream ou ostream, il n'y a qu'un seul pointeur, et pourtant on le différencie comme s'il y en avait 2.

mouais. on clot le débat sur l'héritage multiple. par contre ces cupèdes de C# ils ont pompés comme des malades sur C0x avec leur enum dont on spécifie le type sous-jacent. C'est très cool, bien que peut-être inutile dans un langage plus haut niveau comme C#

C# ca r0x

c'était un message vraiment très intéressant. (et ta citation n'est pas à jour)

autant pour moi, j'ai dit une connerie

 
pour pas changer  
 
 
 
 
(désolé tu tends la perche.. )