Réinitialisation d'un ostringstream

Réinitialisation d'un ostringstream - C++ - Programmation

Marsh Posté le 11-09-2006 à 18:23:18    

Salut,
 
Je voudrais initialiser un ostringstream avec une chaine de caracteres. La methode la plus logique me semble donc :

Code :
  1. ostringstream ostr;
  2. ostr.str("mon_initialisation" );


Oui mais, dans ce cas, si je fais un  

Code :
  1. ostr<<12345;


je vais avoir dans ostr : "12345nitialisation"... Donc a moins de faire un ostr.seekp(quelquechose), ou d'ailleurs je ne sais pas quoi mettre a la place du quelquechose (un sizeof ?), je suis obliger de faire :

Code :
  1. ostr.str("" );
  2. ostr<<"mon_initialisation";


Ce qui me derange un peu, etant donne que mon ostr est une variable generale que j'utilise pour donner des titres a des histogrammes ou des conneries dans le genre, et que donc je l'appelle un certain nombre de fois, mine de rien, et que donc le but serait d'eviter de faire ostr.str("" ) a chaque fois...
 
Ca me paraitrait louche qu'il n'y ait pas plus simple... Comment qu'on fait ???
 
Merci.


Message édité par SkippyleGrandGourou le 12-09-2006 à 20:15:56
Reply

Marsh Posté le 11-09-2006 à 18:23:18   

Reply

Marsh Posté le 11-09-2006 à 19:18:37    

ostringstream ostr("mon_initialisation" );


ou

ostr.str("mon_initialisation" );

Reply

Marsh Posté le 11-09-2006 à 19:27:19    

Oui mais non, visiblement tu n'as dû lire que le titre du topic... ;)

Reply

Marsh Posté le 11-09-2006 à 19:38:25    

oui mais non, visiblement tu ne sais pas ce que veux dire "initialiser" :o
 

Message cité 1 fois
Reply

Marsh Posté le 11-09-2006 à 20:11:50    

Si tu veux prédéfinir une valeur, dérive et c'est torché. Sinon comme tu dis, seek

Message cité 1 fois
Reply

Marsh Posté le 11-09-2006 à 20:47:17    

KangOl a écrit :

oui mais non, visiblement tu ne sais pas ce que veux dire "initialiser" :o

Si-si... :p Ce que je veux faire, c'est me servir de la même ostringstream pour tous mes titres de graphes, etc. Mais comme ils sont tous diférents, il faut que je la réinitialise à chaque fois. Et je trouve ça un peu inutile et bête d'être obligé de passer par un str("" ) pour tout de suite après mettre une string dedans, juste parce que je dois compléter cette string par un entier, par exemple :

Code :
  1. ostr.str("" );
  2. ostr<<"truc"<<Numero;
  4. // parce que ça marche pas :
  5. ostr.("truc" );
  6. ostr<<Numero;


(Évidemment, l'exemple ne présente aucun intérêt, mais étant chez moi j'en ai pas d'autre sous la main). C'est un peu comme ramasser un sucre avec une pelle...
 

Taz a écrit :

Si tu veux prédéfinir une valeur, dérive et c'est torché. Sinon comme tu dis, seek


Le problème c'est que je ne veux pas vraiment prédéfinir une valeur, je veux la reprédéfinir... Le coup du seek, ça ressemble plus à un bulldozer, pour le même sucre...

Reply

Marsh Posté le 11-09-2006 à 21:00:19    

... reprédéfinir ...
 
bon, tu fais << comme tout le monde est voilà.

Reply

Marsh Posté le 12-09-2006 à 12:02:31    

Ouais ben je trouve ca un peu naze (rien de personnel ;) )... Un exemple concret :

Code :
  1. ostringstream ostr;
  2. for (int i=0; i<10; i++)
  3. {
  4.      ostr.str("" );
  5.      ostr<<"numero_"<<i;
  6.      histo[i]->SetName((ostr.str()).c_str());     // ou SetName est une fonction ROOT qui donne un nom a un histogramme, et qui prend traditionnellement un char en argument
  7. }


C'est quand meme moins lisible pour quelqu'un qui ne connait pas les ostringstream qu'un bon vieux :

Code :
  1. char name[200];
  2. for (int i=0; i<10; i++)
  3. {
  4.      sprintf(name,"numero_%i",i);
  5.      histo[i]->SetName(name);     // ou SetName est une fonction ROOT qui donne un nom a un histogramme, et qui prend traditionnellement un char en argument
  6. }


Non ? Pourtant on se tue a me dire qu'il ne faut plus utiliser les sprintf, que les ostringstream c'est l'avenir, etc... Donc j'adapte mon code, mais on m'enlevera pas l'idee que c'est pas super au point.  
 
Quelqu'un peut m'expliquer l'interet de revenir au premier caractere automatiquement apres l'initialisation par str("initialisation" ) ???

Message cité 1 fois
Message édité par SkippyleGrandGourou le 12-09-2006 à 12:03:46
Reply

Marsh Posté le 12-09-2006 à 12:34:41    

SkippyleGrandGourou a écrit :

Donc j'adapte mon code, mais on m'enlevera pas l'idee que c'est pas super au point.  


Mais si mais si. Ton ostringstream c'est un conteneur. C'est donc fait pour rajouter des éléments à la volée. Si tu le veux vide à chaque fois, mets le dans ta boucle et voilà.

Code :
  1. for (int i=0; i<10; i++)
  2. {
  3.       ostringstream ostr;
  4.       ostr<<"numero_"<<i;
  5.       histo[i]->SetName((ostr.str()).c_str());     // ou SetName est une fonction ROOT qui donne un nom a un histogramme, et qui prend traditionnellement un char en argument
  6. }


Reply

Marsh Posté le 12-09-2006 à 13:51:55    

Justement, je l'utilise comme un conteneur generique, il est defini dans mon .h, et je ne le veux pas vide a chaque fois mais le reinitialiser a une valeur "quelconque" avant de rajouter des trucs a la volee dedans.  
 
Ce que j'aimerais donc comprendre (je vois que ce que je veux faire ne semble pas etre possible, donc je me suis fait une raison et utiliserai le ostr.str("" ) a chaque fois), c'est quel avantage il y a a revenir au premier caractere automatiquement apres l'initialisation. Pourquoi ceux qui ont cree le type ostringstream ont que :

Code :
  1. ostr.str("qwerty" );
  2. cout << ostr.tellp() << endl;


affiche 0 plutot que 6, ce qui m'aurait semble plus logique ???

Message cité 1 fois
Message édité par SkippyleGrandGourou le 12-09-2006 à 13:54:31
Reply

Marsh Posté le 12-09-2006 à 13:51:55   

Reply

Marsh Posté le 12-09-2006 à 15:02:37    

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9042
Bon courage si tu veux essayer de les faire bouger :-)

Reply

Marsh Posté le 12-09-2006 à 15:16:39    

t'as qu'à utiliser boost::format

Reply

Marsh Posté le 12-09-2006 à 15:48:38    

Ah oui, effectivement... Donc ok, c'est un bug. Et effectivement je viens de tester chez moi sur gcc 4.0.3, et ca fonctionne normalement, alors qu'ici je travaille sur gcc 3.2.3, qui bugue... Too bad. :cry:  
 
Concernant le boost::format, d'abord merci je connaissais pas, mais mon code devant etre recompilable a souhait par les gens qui l'utilisent je prefere eviter d'utiliser trop de libs non presentes par defaut.

Message cité 1 fois
Message édité par SkippyleGrandGourou le 12-09-2006 à 15:51:28
Reply

Marsh Posté le 12-09-2006 à 16:04:15    

SkippyleGrandGourou a écrit :

Ah oui, effectivement... Donc ok, c'est un bug. Et effectivement je viens de tester chez moi sur gcc 4.0.3, et ca fonctionne normalement, alors qu'ici je travaille sur gcc 3.2.3, qui bugue... Too bad. :cry:  
 
Concernant le boost::format, d'abord merci je connaissais pas, mais mon code devant etre recompilable a souhait par les gens qui l'utilisent je prefere eviter d'utiliser trop de libs non presentes par defaut.


 
Oui, bein pas de bol, le bug est de nouveau présent dans gcc 4.1.1

Reply

Marsh Posté le 12-09-2006 à 16:07:58    

Ah, merde... Reouverture du rapport de bug alors ? Je te laisse l'honneur. ;)

Reply

Marsh Posté le 12-09-2006 à 16:22:52    

MAIS DÉRIVE ET VOILÀ :o
tu vas pas nous ennuyer 10ans pour gagner une ligne de code.

Message cité 1 fois
Reply

Marsh Posté le 12-09-2006 à 16:38:22    

Taz a écrit :

MAIS DÉRIVE ET VOILÀ :o
tu vas pas nous ennuyer 10ans pour gagner une ligne de code.


1) Je suis pas sur de bien comprendre ce que tu entends par "derive"... Tu veux parler d'heritage ?
 
2) C'est pas une ligne de code, mais des dizaines, et c'est dans le but de faciliter la lecture du code. De toute facon, je peux rien y faire puisque je ne peux pas choisir la version de g++ qui sera utilisee, et donc je dois faire au plus general, et donc ce sera ostr.str("" ) et tant pis pour la lecture.
 
3) Un bug qui joue au yoyo avec le numero de version du compilateur, je trouve ca carrement dangereux... :ouch:

Message cité 1 fois
Reply

Marsh Posté le 12-09-2006 à 17:22:43    

------- Comment #2 from pcarlini at suse dot de  2006-09-12 15:10 -------
To be 100% sure, we checked again gcc4.1.1 both on x86-linux and powerc-darwin
and the bug is definitely not there (anymore)
 
Le contraire m'aurait étonné.

Message cité 1 fois
Reply

Marsh Posté le 12-09-2006 à 17:27:08    

GrosBocdel a écrit :

------- Comment #2 from pcarlini at suse dot de  2006-09-12 15:10 -------
To be 100% sure, we checked again gcc4.1.1 both on x86-linux and powerc-darwin
and the bug is definitely not there (anymore)
 
Le contraire m'aurait étonné.


Ben... Ca marche ou pas ?  :??:  

Reply

Marsh Posté le 12-09-2006 à 17:37:12    

chez moi avec gcc 4.1.1 ça ne marche pas, non

Message cité 1 fois
Reply

Marsh Posté le 12-09-2006 à 17:47:11    

SkippyleGrandGourou a écrit :


quel avantage[/b] il y a a revenir au premier caractere automatiquement apres l'initialisation. Pourquoi ceux qui ont cree le type ostringstream ont que :

Code :
  1. ostr.str("qwerty" );
  2. cout << ostr.tellp() << endl;


affiche 0 plutot que 6, ce qui m'aurait semble plus logique ???


 
Leur réponse : parce que c'est le standard.

Message cité 1 fois
Reply

Marsh Posté le 12-09-2006 à 18:03:50    

GrosBocdel a écrit :

chez moi avec gcc 4.1.1 ça ne marche pas, non


GrosBocdel a écrit :

Leur réponse : parce que c'est le standard.


:heink: Mouais, je trouve tout ca un peu brouillon pour du "standard"... Bon ben je crois qu'on va en rester au truc.str("" ) quelle que soit la version, ca me semble plus sur... ;)
 
Merci pour les infos.  :jap:


Message édité par SkippyleGrandGourou le 12-09-2006 à 18:04:09
Reply

Marsh Posté le 12-09-2006 à 18:27:37    

Tu n'as pas interverti tes essais de bouts de code, tu es bien sûr que ça fonctionne avec 4.0.3?

Reply

Marsh Posté le 12-09-2006 à 20:11:26    

Glurps ! J'avions mal lu le bout de code du rapport de bug...  

Code :
  1. std::ostringstream s("abcd", std::ios_base::app);


:whistle:
 
Donc ça ça marche avec gcc 4.0.3, mais pas mon truc. Et ce n'est donc pas un bug, mais simplement une convention "standard" bidon.  :kaola:


Message édité par SkippyleGrandGourou le 12-09-2006 à 20:15:13
Reply

Marsh Posté le 12-09-2006 à 21:18:50    

SkippyleGrandGourou a écrit :

1) Je suis pas sur de bien comprendre ce que tu entends par "derive"... Tu veux parler d'heritage ?

non, je parle d'éradication de la race humaine par la sodomie.

Message cité 1 fois
Reply

Marsh Posté le 13-09-2006 à 02:16:16    


lol t'énerve pas comme ça Taz, tu vas nous faire une colite,
 

Code :
  1. class SLGGstream : public std::ostringstream
  2. {
  3.   public:         
  4.      SLGGstream() {} ;
  5.      SLGGstream(std::string label, int id)
  6.      {
  7.          *this<<label<<id;
  8.      } 
  9. };


puis dans le code appelant

Code :
  1. SLGGstream ostr("number:",777);
  2. ostr<<" tes données"<<endl;   
  4. // ou comme dans ton code magnifique  
  6. for (int i=0; i<10; i++)
  7. {
  8.     histo[i]->SetName(SLGGstream("numero_",i).str().c_str());
  9. }


 
d'une manière générale, crées des wrappers pour faire :
  (*this).str("" );
  (*this).str().c_str();
ETC...

Message cité 1 fois
Reply

Marsh Posté le 13-09-2006 à 11:11:47    

Taz a écrit :

non, je parle d'éradication de la race humaine par la sodomie.


Ah, je savais bien que j'avais mal compris... :o  
 
Desole mais en prog je prefere la pratique a la theorie, alors les noms tels que "derivation", "wrapper" ou autres "cast", je m'en contrebalance... Heureusement que google est la, apres du moment que ca marche... :kaola:  
 

fra0 a écrit :

[exemples pratiques]

Merci, ca m'a l'air bien, je crois que je vais faire comme ca.  :jap:  
 

Message cité 1 fois
Reply

Marsh Posté le 13-09-2006 à 11:43:28    

SkippyleGrandGourou a écrit :

alors les noms tels que "derivation", "wrapper" ou autres "cast", je m'en contrebalance...


c'est certain qu'un mécanicien qui ne fait pas la différence entre un marteau, un tournevis et une molette, il préfère le côté pratique de la mécanique.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed