bonjour,
 
j'ai un soucis bête. j'utilise des objets de type std::istrstream. Pour ce faire, j'utilise le header strstream.

 
problème: g++ me sort des insanités:
 
Dans le fichier inclus `a partir de /usr/include/c++/3.3.1/backward/strstream:51,
          `a partir de Parser.hpp:177,
/usr/include/c++/3.3.1/backward/backward_warning.h:32:2: attention : #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in sect
ion 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warni
ng use -Wno-deprecated.
 
 
mais si ce n'est pas strstream, c'est lequel le fichier à inclure? Je n'arrive pas à trouver, que ce soit avec gcc 3.3.1 ou gcc 3.2.

bin pourtant apparement c'est ce fichier ...

le header <sstream> ça va bien quand on veut utiliser des objets de type std::stringstream, mais pas std::strstream... c'est bien là mon soucis.

fallait lire un peu plus
 
istrstream -> std::istringstream

c'est à dire? je ne comprends pas ta réponse.

les strstream n'existent plus

donc on est obligé d'utiliser un objet qui va dupliquer le buffer sur lequel on veut travailler?

quoi ?

tu n'utilises plus strstream mais stringstream

<humour>
volume+=3dB
donc on est obligé d'utiliser un objet qui va dupliquer le buffer sur lequel on veut travailler?
</humour>
l'avantage d'un objet de type istrtream est qu'il permet(tait) de pouvoir faire une lecture formattée sur un buffer existant. A contrario, la classe istringstream recopie le buffer qu'on lui donne, après quoi on peut faire une lecture formattée.

1) y a pas d'avantage vu que ça n'existe pas. les strinstream sont pour cette meme raison plus surs
2) stop la parano
3) qui t'empêche de jouer avec la machinerie et les streambufs

 
1) enfin ya plus d'avantage vu que ça n'existe plus. Avant ça existait.
Quand à la sûreté, je ne vois pas de quoi tu parles. tu peux préciser?
 
2) euh, de quelle parano il s'agit?
 
3) le temps et l'envie d'utiliser ce qui a déjà été fait, et qui est censé être standard?

1) partager un même buffer pour faire des conneries, ça posait des problèmes
3) au niveau des performances
3) [oi]stringstream sont standards et défini dans <sstream>

1) vu que les implémentation de MS et de SGI ne sont pas thread-safe (cf les compteurs de référence sur les std::string), de toute façon fo faire attention. Normalement, quand on utilise un objet de ce type, on sait qu'on n'a pas le droit d'y toucher avant la fin de son utilisation. Bon, semblerait que maintenant on n'a plus le choix. Il y a sans doute une bonne raison, peut être celle que tu donnes, mais je ne suis pas convaincu.
 
2) pour les perf, je dirais que c'est vrai qu'il ne faut pas être parano, mais ceci, dit, pour avoir du y faire face, trop d'allocation dynamiques pour un logiciel multithread qui est exploité aux limites d'une machine récente (par exemple bi-cpu à 1GHz), sous windows ça peut faire écrouler les perf. je sais, il n'y a pas que windows dans la vie, mais les décideurs ne sont pas toujours d'accord...
 
3) tu as raison, et comme ne restent plus que ceux-ci de standards, et ben je vais devoir les utiliser.
 
Enfin, j'ai ma réponse.
merci.