Instancier [i/o]stream

Bonjour c'est une question toute bete :
Comment puis-je faire pour instancier un ostream ou un istream sans pour autant qu'il soit connecté un a fichier ?

J'ai cru comprendre qu'on pouvait en instancier sur une instance de streambuf mais je n'arrive pas non plus a instancier un streambuf 8O

Le compilateur me parle de "char_traits" ou "<CharT, _Traits>" et je ne vois pas trop ce que c'est... Donc question subsidiaire : que sont les "char_traits" ou "<CharT, _Traits>" ?

Chers développeurs, cheres développeuses ; d'avance merci :)

Un flux n'est par défaut connecté à aucun streambuf.

Code:

---

std::ostream mystream;

---

char est une classe de trait pour les "char"...
Voir le lien : http://alp.developpez.com/tutoriels/traitspolicies/

poukill : Merci c'est parfait, je regarde ça direct :)

Laurent:

Citation:

---

Envoyé par Laurent Gomila

Un flux n'est par défaut connecté à aucun streambuf.

Code:

---

std::ostream mystream;

---

---

Ok ça me rassure d'un coté parce que l'utilisation d'un flux pur sera moins laborieuse que prévue ^^.
En fait mon compilateur se plaint quand j'ajoute "std::ostream mystream;" en private a ma classe.

Voici le message d'erreur : (gcc sous code::blocks)

Code:

---

1 2 3 4 5 6 7 8

/usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include/g++-v4/ostream:342: error: 'std::basic_ostream<_CharT, _Traits>::basic_ostream() [with _CharT = char, _Traits = std::char_traits<char>]' is protected MPacker.cpp:6: error: within this context /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include/g++-v4/ostream:342: error: 'std::basic_ostream<_CharT, _Traits>::basic_ostream() [with _CharT = char, _Traits = std::char_traits<char>]' is protected MPacker.cpp:9: error: within this context /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/include/g++-v4/ostream:342: error: 'std::basic_ostream<_CharT, _Traits>::basic_ostream() [with _CharT = char, _Traits = std::char_traits<char>]' is protected MPacker.cpp:12: error: within this context :: === Build finished: 6 errors, 0 warnings ===

---

et au cas ou voici les lignes 6 à 24 de mon fichier:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

MPacker::MPacker(const char *s){ initClass(s); } MPacker::MPacker(string& s){ initClass(s.c_str()); } MPacker::MPacker(MString& s){ initClass(s.toString()); }   MPacker::~MPacker(){ this->write(); }   void MPacker::initClass(const char *s){ this->canWrite=false; this->iFields=0; this->szFilename.assign(s); }

---

Ah, ben ça veut dire que j'ai dit une bêtise :D
Apparemment on ne peut pas construire un flux par défaut, il lui faut obligatoirement un streambuf. Tu peux toujours tenter de passer NULL à son constructeur, mais je ne suis pas sûr du résultat.

Salut,

Je ne vois pas vraiment ce que tu veux faire...

les istream et ostream sont en fait des variable globales dans l'espace de nomage std et sont "branchés" par défaut sur l'écran (pour ostream) ou sur le clavier (pour istream)

(C'est sûrement pas tout à fait vrai ni tout à fait complet, mais le principe y est ;))

Au mieux, tu peux les "rediriger" vers un autre périphérique ou vers autre chose, mais cela n'a que peu de sens de vouloir en faire un membre privé d'une classe bien précise.

Si tu veux gérer des flux de données au sein d'une classe, ce serait plutôt, selon le cas, un flux fichier (*fstream) ou un flux de conversion de chaine (*stringtream) qu'il faudrait utiliser, non :question:

tu ne confonds pas avec cin et cout ?

istream et ostream sont des typedefs

Code:

---

1 2	typedef basic_istream<char, char_traits<char> > istream; typedef basic_ostream<char, char_traits<char> > ostream;

---

le but serait ici de les utiliser dans un premier temps sans les brancher sur rien.

Cela n'a pas de sens, on souhaite qu'apres la construction on puisse appeler << ou >>.

Il est peut etre preferable de passer par in istream* initialisé a 0 puis de creer l'objet.

Citation:

---

Envoyé par screetch

tu ne confonds pas avec cin et cout ?

istream et ostream sont des typedefs

---

Ah, peut être bien :oops: (sûrement d'ailleurs :P)

Mais je reste convaincu que, dans une large mesure, l'utilisation d'un istream ou d'un ostream comme membre est par trop... générale, et que l'on aurait sûrement intérêt à prévoir un flux un peu plus précis.

Une petite recherche sur basic_istream (étant donné que istream n'en est qu'un typedef ;)) m'a mené, entre autre, à cette information concernant le constructeur:

Citation:

---

Constructor & Destructor Documentation

Code:

---

1 2 3

template<typename _CharT, typename _Traits> std::basic_istream< _CharT, _Traits >::basic_istream ( __streambuf_type * __sb ) [inline, explicit]

---

Base constructor.

This ctor is almost never called by the user directly, rather from derived classes' initialization lists, which pass a pointer to their own stream buffer.

Definition at line 97 of file istream.

---

Cela sous entend que, pour l'appeler, il faut lui fournir un pointeur sur __streambuf_type, mais la doc indique clairement que l'utilisateur ne devrait jamais appeler le constructeur directement et préférer passer les classes dérivées.

Les classes dérivée de basic_istream sont basic_istringstream basic_iostream et basic_fstream, ainsi que le montre le diagramme d'héritage ;)

Ce qui va relativement bien dans le sens de ce que je dis, un istream est peut être un peu trop général pour servir de membre ;)

Citation:

---

Envoyé par koala01

Une petite recherche sur basic_istream (étant donné que istream n'en est qu'un typedef ;)) m'a mené, entre autre, à cette information concernant le constructeur:

Cela sous entend que, pour l'appeler, il faut lui fournir un pointeur sur __streambuf_type, mais la doc indique clairement que l'utilisateur ne devrait jamais appeler le constructeur directement et préférer passer les classes dérivées.

Les classes dérivée de basic_istream sont basic_istringstream basic_iostream et basic_fstream, ainsi que le montre le diagramme d'héritage ;)

Ce qui va relativement bien dans le sens de ce que je dis, un istream est peut être un peu trop général pour servir de membre ;)

---

Ok! Le fait que le compilateur me parle de templates est plus clair a présent!

Et bien en fait mon but et d'avoir un classe qui va jouer le role dans une certaine mesure de manipulateur. Je m'explique : en fait l'utilisation principale est de stocker des données sur un flux que la classe va arranger en structure organisée. Pour l'instant le but principale est effectivement d'obtenir un fichier structuré. Pour le moment je m'en sors avec un stringstream qui va recevoir les données. Le contenu du fichier est donc stocké sous forme de string au sein du flux d'apres ce que j'ai compris.
Le truc c'est que je voudrais que ce flux soit assez générique pour un maximum d'utilisations, par example si j'agrandis ma classe :
qu'elle puisse recevoir aussi bien des données en provenance de strings, de ofstreams, ou bien pourquoi pas des classes de flux "persos" qui acheminerais les données par réseau, ou je ne sais quel autre source ?

Donc en fait ça se trouve un stringstream est assez générique pour tout ça ? Qu'en pensez vous ?

http://kanze.james.neuf.fr/articles-fr.html pourrait t'intéresser ;)
Ca permet de créer des sortes de "filtres".

Pour faire la même chose, il existe une bibliothèque qui fait une grosse partie du boulot à ta place : Boost.Iostreams. Google te donnera tout ce qu'il faut.

Et, je ne fais que proposer la solution, pourquoi ne pas, tout simplement, utiliser un stringstream :question:

De cette manière, tu pourra rajouter tout ce que tu veux avec

Code:

---

ss<<l_info

---

et la récupérer au bon format avec

Code:

---

ss>>la_variable

---

Cela permet une gestion "indirecte" (à préciser au fur et à mesure de l'évolution) de ton problème non :question:

Les liens que j'ai donné expliquent comment filtrer/formater à notre guise des échanges dans les flux.

OK super merci pour les liens je vais voir ce que je peux faire avec les stringstreams :)