C'est exactement ca. Ca marche comme le cout et comme tous les flux. Utilise plutôt ostringstream qui n'est dédié qu'à la sortie. J'ai aussi mis du temps à me lancer, mais j'en avais marre de faire des sprintf( s, "%d", i ); et des trucs comme ca :)
-- -------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
C'est exactement ca. Ca marche comme le cout et comme tous les flux.
Utilise plutôt ostringstream qui n'est dédié qu'à la sortie.
J'ai aussi mis du temps à me lancer, mais j'en avais marre de faire des
sprintf( s, "%d", i ); et des trucs comme ca :)
--
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/
C'est exactement ca. Ca marche comme le cout et comme tous les flux. Utilise plutôt ostringstream qui n'est dédié qu'à la sortie. J'ai aussi mis du temps à me lancer, mais j'en avais marre de faire des sprintf( s, "%d", i ); et des trucs comme ca :)
-- -------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Michaël Monerau
Zouplaz wrote:
Mickael Pointier - :
Tu es en Release, ou en Debug ?
Est-ce que ca fait pareil si tu _utilises_ "truc", par exemple en rajoutant un cout<<truc; juste avant le "return 0;" ?
En debug. Il y a un bug dans le debugger de vsnet 2002 qui empêche la visualisation correcte du contenu d'une std::string si elle fait + de 16 caractères. Il faut bidouiller un fichier pour que ça fonctionne.
Ce n'est pas un bug, mais une limitation du debugger. En effet, comme c'est une commande de script indépendante du contexte, le debugger t'affiche la valeur d'un membre de l'objet. Mais comme la gestion des buffers est assez complexe dans un std::string (pour des raisons de rapidité que je ne connais pas), le debugger s'emmêle un peu les crayons. Je m'étais fait avoir pareil :p
Finalement, j'avais corrigé tout ça en faisant apparaître les *deux* buffers dans l'info bulle, et suivant le cas, je regardais l'un ou l'autre (ça se voit facilement :p). Ca marchait très bien !
Il est à noter que dans 7.1, tout ça est corrigé, et marche tout seul sans bidouille (l'info-bulle marche parfaitement, quelque soit le buffer en cours). -- <=- Michaël "Cortex" Monerau -=> "OK, We'll call it a draw" - Monthy Python
Zouplaz wrote:
Mickael Pointier - mpointie@eden-games.moc :
Tu es en Release, ou en Debug ?
Est-ce que ca fait pareil si tu _utilises_ "truc", par exemple en
rajoutant un cout<<truc; juste avant le "return 0;" ?
En debug. Il y a un bug dans le debugger de vsnet 2002 qui empêche la
visualisation correcte du contenu d'une std::string si elle fait + de
16 caractères. Il faut bidouiller un fichier pour que ça fonctionne.
Ce n'est pas un bug, mais une limitation du debugger. En effet, comme c'est
une commande de script indépendante du contexte, le debugger t'affiche la
valeur d'un membre de l'objet. Mais comme la gestion des buffers est assez
complexe dans un std::string (pour des raisons de rapidité que je ne connais
pas), le debugger s'emmêle un peu les crayons. Je m'étais fait avoir pareil
:p
Finalement, j'avais corrigé tout ça en faisant apparaître les *deux* buffers
dans l'info bulle, et suivant le cas, je regardais l'un ou l'autre (ça se
voit facilement :p). Ca marchait très bien !
Il est à noter que dans 7.1, tout ça est corrigé, et marche tout seul sans
bidouille (l'info-bulle marche parfaitement, quelque soit le buffer en
cours).
--
<=- Michaël "Cortex" Monerau -=>
"OK, We'll call it a draw" - Monthy Python
Est-ce que ca fait pareil si tu _utilises_ "truc", par exemple en rajoutant un cout<<truc; juste avant le "return 0;" ?
En debug. Il y a un bug dans le debugger de vsnet 2002 qui empêche la visualisation correcte du contenu d'une std::string si elle fait + de 16 caractères. Il faut bidouiller un fichier pour que ça fonctionne.
Ce n'est pas un bug, mais une limitation du debugger. En effet, comme c'est une commande de script indépendante du contexte, le debugger t'affiche la valeur d'un membre de l'objet. Mais comme la gestion des buffers est assez complexe dans un std::string (pour des raisons de rapidité que je ne connais pas), le debugger s'emmêle un peu les crayons. Je m'étais fait avoir pareil :p
Finalement, j'avais corrigé tout ça en faisant apparaître les *deux* buffers dans l'info bulle, et suivant le cas, je regardais l'un ou l'autre (ça se voit facilement :p). Ca marchait très bien !
Il est à noter que dans 7.1, tout ça est corrigé, et marche tout seul sans bidouille (l'info-bulle marche parfaitement, quelque soit le buffer en cours). -- <=- Michaël "Cortex" Monerau -=> "OK, We'll call it a draw" - Monthy Python
