Reprise du message précédent :
ouais le taf c'est un sacré tue-projet-perso

houla t'es encore tombé sur un beau truc toi

la vie serait tellement plus simple si on avait pas à bouffer, comme ça pas besoin de taffer pour bouffer, et si y'a des prises secteurs dans la rue, on peu coder dans une boite a carton...
 
"bonjour vous êtes sdf ?"
- non je suis developpeur freelance"
 
enfin la vie tout ça quoi...

 
ha non mais y'a des trucs surrealistes, le pire c'est qu'on vends les softs à je sais pas combien de K€
mais on a pas de concurrents hahahaha

oué enfin vu que t'es obligé de patauger dans le caca pour ce faire .....
 
c'est des softs de quoi ?

de simulation approximative (mais suffisante) pour former des techniciens dans un milieu spécifique. (je peux pas plus préciser, avec google faut faire gaffe)

mais le truc marche mine de rien et remplit sa fonction

bon aller a deminche   (faudrait ptet renommer le topic blabla@chrisbk)

bk> bon, j'ai un élément de réponse. Il était une fois la bibliothèque classic IOsteams. Celle-ci était quelque peu différente de l'actuelle standard IOStreams. Entre autre, on pouvait appeler pubsetbuf, et lui passer un buffer. Cette fonctionnalité n'a pas été standardisé, car la durée de vie du buffer que l'on fournissait était sujet à erreurs. Cette fonction a été maintenu quand même, et seul l'appel à pubsetbuf(0,0) a un comportement défini par la norme, aussi bien dans basic_stringbuf que dans basic_filebuf (contrairement à ce que j'ai eu dit). Tout autre appel est implementation defined.
 
au fait, sans le passage par std::string ? Eventuellement en faisant un prétraitement sur s :
char const* s = "pouet pouet";
std::istringstream( s );
 
tu ne peux pas faire mieux, la copie de s dans le buffer interne du istringstream est requise, pour éviter les erreurs encore une fois. Sauf erreurs, c'était différent dans classic IOStreams et ses strstream, et falait le permis de conduire pour s'en servir.

Ce genre de fonction conservée pour compatibilité, surtout que rien n'est défini dans la norme, et donc qu'elle ne sert à rien pratiquement... Elle n'aurait pas dû être notée comme dépréciée ?

 
difficile de déprécier seulement les appels de pubsetbuf(x,y) avec x != 0 || y != 0. Apparemment, ils ont choisi d'en confier la resposabilité à l'implémentation. ça casse du code, donc on peut comprendre. Mais je trouve ça moyen aussi

 
 
alors mon pb c'est que c'est pas du texte que je mets dans mon istringstream, mais du binaire. donc j'utilise le constructeur std::string(const char *, size_t size) (ou dans le gout). J'ai donc peur de me taper une double copie (char => string => buffer interne)
 
merci pour les precisions !

 
de l'autre coté c'est super dangeureux car completement silencieux a la compilation

sauf dans le stlport de borland : setbuf(0,0) ne fait rien du tout :/

 
manipuler le buffer d'un stream n'est pas une bonne idée...  
tu es sur que le stream est vraiment le meilleur objet pour faire ce que tu dois faire ?
personnellement, j'utilise a présent un std::deque<char> couplé avec std::copy pour le copier dans un stream

 
tu dois parler de basic_stringbuf, comme dit en première page, la norme garanti que basic_stringbuf::setbuf(0,0) soit sans effets.
 

 
 
?
 
bin ouais, vu que derriere j'ai des fonctions qui attendent un istream (ifstream, istringstream, whatever)

effectivement, j'ai encore mal traduit except  
 
bon oubliez ce que j'ai dit a propos de setbuf...
 
ps : saleté de wifi  

heuh chui ptet pas reveillé, mais pourquoi ce machin la ne m'affiche pas "0" ?

 
(gcc 2.95)

Au fait, je me rappelle que la STL définit les ropes.

certes, mais c'est pas la question

ça sent la choucroute à mon avis

En fait, c'est seulement une extension SGI. Il me semblait que GNU l'implémentait aussi, mais je n'en suis pas sûr.

ça marche nickel sous VS 2005
 

#include <iostream>
#include <sstream>
#include <string>
 
int main(void)
{
    std::istringstream st(std::string("prout" ),std::ios::in|std::ios::binary);
    std::cout<<"pos : "<<st.tellg()<<std::endl;
}

ça va l'aider beaucoup ça

ça va au moins lui montrer que ce n'est pas une erreur de sa part, mais qu'il utilise un compilo pourri

bin toi au lieu de poster du mlc, installe gcc2.95 sur ton nux, et essaye (ca marche avec gcc 3.x et 4.0, jpige pas trop )

 
nan mais ca je sais
 
au fait y'a des changements dans le compilo C++ de vs 2005 ?

tiens bin harko, t'avais pas installé un gcc 2.95 y'a pas longtemps sur une VM ? tu pourrais regarder, paske j'ai un doute sur mon install...

j'crois que j'ai une merde dans mon install également

lol moi j'ai l'impression qu'il cherche les header de la std de gcc 3.0, donc jme demande si ca couille pas la

ben vu que moi je semble avoir un problème de headers également, j'ai un doute sur la cohabitation entre 2.95 et 3.0

monde de merde

 
si la distri utilise un système de paquets et que c'est fait proprement, pas de problèmes.
 

j'ai la meme merde
c'est quoi ce delire ?
 
(merci btw)

 
g++  

The 2.95 series of the compiler is no longer developed.  If you do not
want to be told to switch to a current g++ (2.95.3 is obsolete since
June 2001, i.e. *2* *years* ago), you may want to have a look to the
source code and fix the problem yourself.  
 
 
k, lol.

J'étais tombé dessus aussi celui là    
 
si tu fais un st.seekg (0, std::ios::beg); avant affichage ça change quelque chose ?

 
nan, ca chie des glacons pareil. Par contre le resultat a l'air faux, mais coherent, autrement dit si tu veux avoir la taille du fichier tu fais  
 

 
 
m'enfin c'est merdique. Les fstream fonctionnent correctement, eux

mouais, moi j'abandonne
 
j'ai trouvé ça sinon  
 
En fait, la norme évite soigneusement à dire ce que peut être ou ne
pas peut être le type de streampos. Ce qui a fait l'objet du DR 6. En
somme, la norme est claire, et c'est simplement moi qui est trop idiot
pour la comprendre. (Apparamment, Matt Austern l'a pas trouvée assez
claire non plus, et dans son commentaire, il a l'air d'impliquer que
Jerry [Schwarz -- auteur des iostream chez AT&T] non plus. Alors, je
me sens pas trop mauvais.) Si on prend la réponse du comité
littéralement, streampos serait typiquement un fpos_t avec des
opérateurs en plus. Et selon la norme C, un fpos_t, c'est de la magie.
 
James Kanze
 
La norme C++ est affreusement imprécis en ce qui concerne streampos et
streamoff. Ce n'est donc pas toujours très clair ce qui doit
fonctionner, et ce qui n'est pas garanti. J'imagine que dans la
pratique, streampos va toujours donner les garanties de fpos_t en C,
et streamoff va toujours être un type entier (parce que
fonctionnellement, il correspond au long passé à lseek en C). Mais en
C, fpos_t est un type transparent -- l'utilisateur ne peut pas
l'initialiser, on ne peut pas le créer à partir d'un int, etc. C++
exige d'opérateurs supplémentaires, sans vraiment définir leur
sémantique.
 
Faute d'autres précisions, je programme comme si j'avais les garanties
de C pour ces deux types, c-à-d :
 
  - Je ne compte pas sur la capabilité de convertir streampos en
    entier, ni sur la sémantique de la conversion d'un entier en
    streampos. Pour moi, streampos est un type transparent, un « magic
    cookie » dont la structure et la signification ne sont connues que
    de l'implémentation. Je n'utilise que des streampos qui m'ont été
    rétournés par des fonctions de positionnement.
 
  - Si je veux positionner quelque part sans l'avoir forcemment visité
    (et en avoir mémorisé le streampos) avant, j'utilise le forme de
    seek qui prend un streamoff et un seekdir. Et je ne compte que sur
    les garanties de lseek dans la norme C, c-à-d :
 
    binary :
        Fonctionne en général. En fait, les seek à ios::end ne sont
        pas garantis, mais dans la pratique, ils fonctionnent sur les
        machines qui m'interessent.
 
    text :
        Fonctionne seulement si le streamoff est 0. Donc, je peux me
        positionner au début ou à la fin, mais pas à un endroit
        arbitraire dans le fichier.
 
Enfin, je ne compterais même pas que le mode binary ait une
signification utile pour les flux autres que char.
 
James Kanze
 
http://groups.google.fr/group/fr.c [...] 206ac5834c