Reprise du message précédent :
c'est amurofl

 
dac, mais l'ennui, c'est que ce ne sont ni les experts, ni meme les connaisseurs en str*buf qui courent les rues
Sinon, les stringstream, c'est chouette, c'est pratique. Mais si le profiler (ou l'intuition crisbkienne) dit qu'il y a problème, alors le stringstream en question risque bien de retourner dans ses 22.  

 
bin ouais, j'ai fait des recherches google sur le sujet et suis revenu brocouille. C'est penible
 

 
bof jsais pas, derriere j'ai pas mal de lecture petit morceau par petit morceau, donc soit c'est ca (stringstream) soit c'est des acces a un fichier (certe bufferisé), donc je sais pas trop c'est quoi le mieux. Pour le coup je suis pas trop inquiet sur les perfos de lecture, c'est plus le bete gachis qui me gene. (enfin de toute facon j'en ai besoin, ou alors je reecris mon istream a moi sur cette fonction 'monread' et chui pas super motiv, en fait)
 
 
 

 
J'ai un beau bouquin sur iostreams/locale (A. Langer, K. Kreft), mais les passages sur les str*buf, j'ai du mal à les avaler
 

 
mouais, sinon, quand tu crée ton istringstream, tu utilises un temporaire string, c'est en partie ce qui te gène apparemment. Je ne suis pas convaincu que l'optimiseur n'ai pas l'opportunité de sucrer purement et simplement ce temporaire ... Ce serait déjà ça de gagner.

 
bin de toute facon y'a pas grand chose a faire, le stringbuf a VS a pas l'air de faire grand chose
 

 
Faudrait aller voir au disasm ce qu'il se passe reelement, et faire du #define pour passer en rd()->pubsetbuf sous GCC histoire de
 
le truc que je sais pas, c'est si un rd()->pubsetbuf()  prends la responsabilité de la desallocation du pointeur qu'on lui file ?
 
 

Je dédie cette chanson à Chrsibk qui n'a pas peur de mettre les mains dans la merde
                         (un proctologue de génie dixit sa soeur)
                      ________________   __________________
                                                \/
               

Mékilécon ce chou-fleur    

Découpe. Ca te fera 15 lignes au lieu de 3, c'est tout. Me dis pas que c'est pas à ta portée.

Bon, je viens d'éplucher la norme, pubsetbuf appelle la fonction virtuelle protégé setbuf. les classes dérivant de basic_streambuf doivent overrider cette fonction. basic_filebuf::setbuf a un comportement défini, mais basic_stringbuf::setbuf est implementation defined (sauf que setbuf(0,0) doit etre sans effet). Donc si gcc fait quelquechose, c'est son droit, si VS ne fait rien, c'est son droit aussi.
 

 
pourquoi pas, c'est une façon de gérer l'implementation defined. Mais consulte la documentation de gcc, pour savoir dans quelles version ça marche de la façon qui te convient.
 

AHMA non.

 
et comment on fait du code portable avec du implementation defined  dans la STL ?
 
 
 
 

 
bon bin alors non, tant pis

PARCE QUE OUI JESSAYE DE FAIRE DU PROTABLE ET PTAIN CE QUE CAI CHIANT §§§

bah, c'est pas chiant le portable !
regarde moi par exemple : tous mes softs sont portables ! ils tournent sous Win 95, Win 98, Win NT, 2000, XP et 2003

 
un R en trop ?  

 
meme pas, j'ai tout cassé la portabilité w98  
 
jte parlais de portabilité entre compilo, jeune veau, a partir du moment ou tu utilises une hashmap en c++ t'es mal barré
 

 
non, mal placé, c'est ca le stayle
 

facile, avec des #ifdef dans tout les sens Comme c'est le cas quand on veut etre portable vers les vieux compilos, les compilos cassés, les compilos qui fournissent des extensions puantes, etc ...
mais je crois que t'es tombé sur quelquechose de bien exotique. J'aimerais bien connaitre la raison profonde de ce implementation-defined ...

 
ouais m'enfin merde, que les compilos implante le standart mal, ok, bon, genre gcc 2.95 qui aime pas les namespace aliasing sur std ou les guignoleries a VS<7.1, mais que la STL dise "bon, alors pour ce qui se passe c'est vous qui voyez nous on s'en bas les braies', c'est un peu n'imp. Le T de STL devient guignolesque !

pas STL, IOStreams    
 
S'il y a ID, c'est qu'il y a surement une bonne raison. J'essayerai de me renseigner, l'explication doit valoir son pesant de cacaouettes, je pense.

ouais bon, IOStream fait partie de la STL
 
bin si tu trouves hesite pas a poster, ca m'interesse aussi

bk >> tu noteras que je t'avais filé le pourquoi du comment de ton problème hier, mais que t'en as rien eu à battre
 
http://forum.hardware.fr/hardwaref [...] m#t1257072

nan mais comme je t'ai dis, ca c'est pour stream_buf et dans un istringstream c'est pas un stream_buf mais un string_buf, et d'une, et de deux ca explique que dalle sur la difference gcc / vs, donc je te prierais d'aller faire un bonhomme de caca et de laisser les adultes entre eux

non mais on s'en fout putain, ça te dit bien que le comportement par défaut de setbuf() est de renvoyer this, et que c'est à toi de l'implémenter dans une classe dérivée, soit exactement ce que t'a expliqué ++fab plus haut
 
edit: surtout que stringbuf hérite de streambuf

SL contient STL + [ IOStreams et Locale ] en gros
 
 

Yep

 
mais phoque
jte parle de std::istringstream, pas d'une obscure classe parent quoi. Faut quand meme pas que j'aille bricoler std::istringstream, tout de meme ?
 
en particulier

 
bin elle est pas redefined, et donc ca behave pas du tout as espected

y'a pas marqué "that must be", mais "that should be" ! la redéfinition n'est pas obligatoire

nan mais, ok, d'accord, lol
 
et apres ?

Comme c'est un accès direct au buffer lui-même, c'est peut-être une histoire d'indiens ou de thread safety.
 
Mais l'interprétation de la norme par la STL de VS me parait un peu extrême, tout de même. Cela voudrait dire qu'elle interdit l'accès au buffer.

bha merci bk, comme je vois je vais avoir des problèmes lundi moi

 
ha merde j'en fous partout pour mes collections de textures & autres ressources

 
non, tu y a acces via basic_str*stream<>::rdbuf(). Le fait que basic_streambuf<>::pubsetbuf renvoye en cas de succes 'this' , c'est je crois juste pour tester que la fonction a accompli son devoir, sinon, elle renvoie 0.

 
bouge pas
 

 
vala, t'as plus qu'a utiliser HashNamespace::hash_map
 
easy non ?

pour contre je garanti rien pour VS6 et m'en fou copieusement

interressant.
 
squoi le prob avec le hashage de std::string dans VC7, il se chies dessus ?
apparement le 7.1 a pas le problème ?

semblerait (nouveauté du jour, si on en croit les messages du compilo) que std::string n'ai pas la redefinition de l'operateur size_t et donc ne puisse pas etre utiliser directement comme clé de hash_map

ha bon.. ye ché pu si je faisais déjà mes hash_map<std::string,T> avec VC7.
 
enfin bon on est au vs 2005, alors qu'ils fassent pas chier ceux qui sont en vc7, et que ceux qui sont en vc6 crèvent...

ah bin jte dis ca, vu que tu bosses sur le mighty project gnu gcc libre open source portable ...

le simulateur de steak volant avec possibilitées commerciales entre le cholestérol et le sel marin ?
 
bin oui & non, je mets dispo mon tas de foin, mais pour le moment je suis ma propre ligne marron

rude coup, tu veux dire que t'essaye meem pas de compiler quotidiennement ton code sur AIX avec un opengl 1.1 des familles ?

bin non ma pauvre dame  

Ou va le monde
 
t'as avancé dans ton machin?

visuellement non, mais je débuggues et j'assaini (karcher, sarko tout ça), maintenant ça crashes plus quand j'oublies que j'avais mis de l'antialiasing dans le fichier de config, et qu'un pauvre triste essayes sur sa radeon pas 8000.
 
j'ai pas encore commencé de tout refaire le plugin d'export avec IGame, passke là j'en peux plus j'ai plus d'aspirine

et j'ai le taf qui me suce le cerveau avec du code de merde d'il y a 10 ans qui lit des collections de données depuis des fichiers .INI sans fonctions ni structures, sans malloc/free avec du copier-coller partout.... (genre soft à la con qui pour 4 combo prends autant de temps que 3ds pour faire un render sur un objet 30Ktriangles) (et en plus dans des .cpp ou le seul truc++ existant c'est visualstudio qui l'a fait)

ouais le taf c'est un sacré tue-projet-perso