Je planche actuellement sur un serveur web, et je dois "fragmenter"
l'envoi de mes donnees pour ne pas bloquer X clients lorsqu'un
telecharger un fichier... Disons en blocs de 5Ko. Neanmois, je n'y
arrive absolument pas, ma lecture plante avec un tellg qui renvoit -1
comme taille, et une concat qui foire, donc :(
Code:
ifstream fileStream;
unsigned int size;
char tmp[4096;]
fileStream.open(file.c_str(), ios_base::in | ios_base::binary); //file
est un string recuperee dans un autre endroit du code
cerr << "opened ? " << fileStream.is_open() << endl; // affiche 1
cerr << "good ? " << fileStream.good() << endl; // affiche 1
request.append("rnContent-Length: ");
fileStream.seekg(0, ios_base::end);
size = fileStream.tellg();
oss << size;
request.append(oss.str());
request += "rn";
request.append("Accept-Ranges: bytesrn");
request.append("Connection: keep-alivernrn"); // Separation du
header et du body par une paire de "rn"
if (*idx > 0){ //*idx est un pointeur sur un int qui permet de
reprendre la lecture la ou on l'avait laissee...
cerr << "clearing requestn";
request.clear(); // si on passe ici, on a pas besoin de header (en
theorie)
fileStream.seekg(*idx);}
else
fileStream.seekg(0, ios_base::beg);
long pos = (long)fileStream.tellg() - *idx; // Je souhaitais pouvoir
me placer dans mon tmp pour mettre le ' ', mais tellg me renvoit
toujours -1 :(
cerr << "opened ? " << fileStream.is_open() << endl; // renvoi 1
cerr << "good ? " << fileStream.good() << endl; // renvoi 1
fileStream.read(tmp, 4095); // char tmp[4096]... 1 octet pour mettre
le ' ' (habitude unix... bonne ou pas ?)
cerr << "tellg: " << (long)fileStream.tellg() << endl; // renvoi -1
cerr << "idx: " << *idx << endl; // renvoi 0
cerr << "pos: " << pos << endl; // renvoi -1
//tmp[pos] = ' '; // donc logiquement ca pete ici
*idx = (long)fileStream.tellg(); // je garde en memoire la valeur de
lecture pour reprendre plus tard
if (*idx == size){ // si le fichier est complet, on met idx a -1 pour
que la fonction appellante close la socket.
cerr << "Reseting *idx to -1";
*idx = -1;
request.append(tmp);
request += "rn";}
else
request.append(tmp);
Je planche actuellement sur un serveur web, et je dois "fragmenter"
l'envoi de mes donnees pour ne pas bloquer X clients lorsqu'un
telecharger un fichier... Disons en blocs de 5Ko. Neanmois, je n'y
arrive absolument pas, ma lecture plante avec un tellg qui renvoit -1
comme taille, et une concat qui foire, donc :(
Code:
ifstream fileStream;
unsigned int size;
char tmp[4096;]
fileStream.open(file.c_str(), ios_base::in | ios_base::binary); //file
est un string recuperee dans un autre endroit du code
cerr << "opened ? " << fileStream.is_open() << endl; // affiche 1
cerr << "good ? " << fileStream.good() << endl; // affiche 1
request.append("rnContent-Length: ");
fileStream.seekg(0, ios_base::end);
size = fileStream.tellg();
oss << size;
request.append(oss.str());
request += "rn";
request.append("Accept-Ranges: bytesrn");
request.append("Connection: keep-alivernrn"); // Separation du
header et du body par une paire de "rn"
if (*idx > 0){ //*idx est un pointeur sur un int qui permet de
reprendre la lecture la ou on l'avait laissee...
cerr << "clearing requestn";
request.clear(); // si on passe ici, on a pas besoin de header (en
theorie)
fileStream.seekg(*idx);}
else
fileStream.seekg(0, ios_base::beg);
long pos = (long)fileStream.tellg() - *idx; // Je souhaitais pouvoir
me placer dans mon tmp pour mettre le ' ', mais tellg me renvoit
toujours -1 :(
cerr << "opened ? " << fileStream.is_open() << endl; // renvoi 1
cerr << "good ? " << fileStream.good() << endl; // renvoi 1
fileStream.read(tmp, 4095); // char tmp[4096]... 1 octet pour mettre
le ' ' (habitude unix... bonne ou pas ?)
cerr << "tellg: " << (long)fileStream.tellg() << endl; // renvoi -1
cerr << "idx: " << *idx << endl; // renvoi 0
cerr << "pos: " << pos << endl; // renvoi -1
//tmp[pos] = ' '; // donc logiquement ca pete ici
*idx = (long)fileStream.tellg(); // je garde en memoire la valeur de
lecture pour reprendre plus tard
if (*idx == size){ // si le fichier est complet, on met idx a -1 pour
que la fonction appellante close la socket.
cerr << "Reseting *idx to -1";
*idx = -1;
request.append(tmp);
request += "rn";}
else
request.append(tmp);
Je planche actuellement sur un serveur web, et je dois "fragmenter"
l'envoi de mes donnees pour ne pas bloquer X clients lorsqu'un
telecharger un fichier... Disons en blocs de 5Ko. Neanmois, je n'y
arrive absolument pas, ma lecture plante avec un tellg qui renvoit -1
comme taille, et une concat qui foire, donc :(
Code:
ifstream fileStream;
unsigned int size;
char tmp[4096;]
fileStream.open(file.c_str(), ios_base::in | ios_base::binary); //file
est un string recuperee dans un autre endroit du code
cerr << "opened ? " << fileStream.is_open() << endl; // affiche 1
cerr << "good ? " << fileStream.good() << endl; // affiche 1
request.append("rnContent-Length: ");
fileStream.seekg(0, ios_base::end);
size = fileStream.tellg();
oss << size;
request.append(oss.str());
request += "rn";
request.append("Accept-Ranges: bytesrn");
request.append("Connection: keep-alivernrn"); // Separation du
header et du body par une paire de "rn"
if (*idx > 0){ //*idx est un pointeur sur un int qui permet de
reprendre la lecture la ou on l'avait laissee...
cerr << "clearing requestn";
request.clear(); // si on passe ici, on a pas besoin de header (en
theorie)
fileStream.seekg(*idx);}
else
fileStream.seekg(0, ios_base::beg);
long pos = (long)fileStream.tellg() - *idx; // Je souhaitais pouvoir
me placer dans mon tmp pour mettre le ' ', mais tellg me renvoit
toujours -1 :(
cerr << "opened ? " << fileStream.is_open() << endl; // renvoi 1
cerr << "good ? " << fileStream.good() << endl; // renvoi 1
fileStream.read(tmp, 4095); // char tmp[4096]... 1 octet pour mettre
le ' ' (habitude unix... bonne ou pas ?)
cerr << "tellg: " << (long)fileStream.tellg() << endl; // renvoi -1
cerr << "idx: " << *idx << endl; // renvoi 0
cerr << "pos: " << pos << endl; // renvoi -1
//tmp[pos] = ' '; // donc logiquement ca pete ici
*idx = (long)fileStream.tellg(); // je garde en memoire la valeur de
lecture pour reprendre plus tard
if (*idx == size){ // si le fichier est complet, on met idx a -1 pour
que la fonction appellante close la socket.
cerr << "Reseting *idx to -1";
*idx = -1;
request.append(tmp);
request += "rn";}
else
request.append(tmp);
Concernant tellg, au temps pour moi, c'est normalement un long...
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
Concernant tellg, au temps pour moi, c'est normalement un long...
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
Concernant tellg, au temps pour moi, c'est normalement un long...
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
À moins que tu fasses des entrées/sorties asynchrones orientées é vénement ?
Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
À moins que tu fasses des entrées/sorties asynchrones orientées é vénement ?
Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
À moins que tu fasses des entrées/sorties asynchrones orientées é vénement ?
On 2 avr, 15:06, Mathias Gaunard wrote:Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
Non, non, je t'assure que j'en bouffe pas mal depuis le debut :)
Mais en l'occurence, et d'apres la MSDN:
"Return Value
A streampos type, corresponding to a long."
Apres je n'ai pas assez de connaissances et de capacites pour
contredire la msdn ^_^
On 2 avr, 15:06, Mathias Gaunard <loufo...@gmail.com> wrote:
Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
Non, non, je t'assure que j'en bouffe pas mal depuis le debut :)
Mais en l'occurence, et d'apres la MSDN:
"Return Value
A streampos type, corresponding to a long."
Apres je n'ai pas assez de connaissances et de capacites pour
contredire la msdn ^_^
On 2 avr, 15:06, Mathias Gaunard wrote:Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
Non, non, je t'assure que j'en bouffe pas mal depuis le debut :)
Mais en l'occurence, et d'apres la MSDN:
"Return Value
A streampos type, corresponding to a long."
Apres je n'ai pas assez de connaissances et de capacites pour
contredire la msdn ^_^
Desole des oublis, c'est que j'ai tire le code d'une fonction ( que je
n'ai maintenant plus, pour cause de modifications lourdes)...
oss est en effet un ostringstream, j'ai pris cette methode sur
developpez.com pour convertir les donnes en int...
Concernant tellg, au temps pour moi, c'est normalement un long...
Cependant, codant pour Windows, je n'ai trouve que cette maniere la de
connaitre la taille :(
Pour idx, c'est l'abreviation d'index, pour savoir ou en est la
lecture dans le fichier.
Concernant pos, je l'avais defini dans le code meme, pour le , mais
vu que c'est inutile, a zapper :)
Et enfin, pour la complexite, je m'explique : Je fais un serveur web,
donc si je devais rester bloque dans ma boucle pour l'envoi de donnees
vers un client, les autres clients geres par la thread seraient, eux,
bloques :(
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
Desole des oublis, c'est que j'ai tire le code d'une fonction ( que je
n'ai maintenant plus, pour cause de modifications lourdes)...
oss est en effet un ostringstream, j'ai pris cette methode sur
developpez.com pour convertir les donnes en int...
Concernant tellg, au temps pour moi, c'est normalement un long...
Cependant, codant pour Windows, je n'ai trouve que cette maniere la de
connaitre la taille :(
Pour idx, c'est l'abreviation d'index, pour savoir ou en est la
lecture dans le fichier.
Concernant pos, je l'avais defini dans le code meme, pour le , mais
vu que c'est inutile, a zapper :)
Et enfin, pour la complexite, je m'explique : Je fais un serveur web,
donc si je devais rester bloque dans ma boucle pour l'envoi de donnees
vers un client, les autres clients geres par la thread seraient, eux,
bloques :(
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
Desole des oublis, c'est que j'ai tire le code d'une fonction ( que je
n'ai maintenant plus, pour cause de modifications lourdes)...
oss est en effet un ostringstream, j'ai pris cette methode sur
developpez.com pour convertir les donnes en int...
Concernant tellg, au temps pour moi, c'est normalement un long...
Cependant, codant pour Windows, je n'ai trouve que cette maniere la de
connaitre la taille :(
Pour idx, c'est l'abreviation d'index, pour savoir ou en est la
lecture dans le fichier.
Concernant pos, je l'avais defini dans le code meme, pour le , mais
vu que c'est inutile, a zapper :)
Et enfin, pour la complexite, je m'explique : Je fais un serveur web,
donc si je devais rester bloque dans ma boucle pour l'envoi de donnees
vers un client, les autres clients geres par la thread seraient, eux,
bloques :(
A moins que je n'appelle une autre thread dediee a la lecture du
fichier ... ?
In article ,
NaeiKinDus wrote:On 2 avr, 15:06, Mathias Gaunard wrote:Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
Non, non, je t'assure que j'en bouffe pas mal depuis le debut :)
Mais en l'occurence, et d'apres la MSDN:
"Return Value
A streampos type, corresponding to a long."
Apres je n'ai pas assez de connaissances et de capacites pour
contredire la msdn ^_^
Il y a autre chose que la MSDN dans la vie !
La norme,
elle, decrit:
pos_type tellg();
sans plus d'explications.
En cherchant un peu, on trouve la definition de pos_type dans
basic_streambuf. C'est donc un type qui est dependant de l'objet que tu
manipules... (defini en traits du type caractere qui t'interesse).
Les traits par defaut te donnent effectivement streampos pour char,
wstreampos pour wchar.
streampos *peut* etre implemente par un long.
In article <1175519979.435665.31...@y80g2000hsf.googlegroups.com>,
NaeiKinDus <naeikin...@gmail.com> wrote:
On 2 avr, 15:06, Mathias Gaunard <loufo...@gmail.com> wrote:
Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
Non, non, je t'assure que j'en bouffe pas mal depuis le debut :)
Mais en l'occurence, et d'apres la MSDN:
"Return Value
A streampos type, corresponding to a long."
Apres je n'ai pas assez de connaissances et de capacites pour
contredire la msdn ^_^
Il y a autre chose que la MSDN dans la vie !
La norme,
elle, decrit:
pos_type tellg();
sans plus d'explications.
En cherchant un peu, on trouve la definition de pos_type dans
basic_streambuf. C'est donc un type qui est dependant de l'objet que tu
manipules... (defini en traits du type caractere qui t'interesse).
Les traits par defaut te donnent effectivement streampos pour char,
wstreampos pour wchar.
streampos *peut* etre implemente par un long.
In article ,
NaeiKinDus wrote:On 2 avr, 15:06, Mathias Gaunard wrote:Concernant tellg, au temps pour moi, c'est normalement un long...
Toujours pas non.
C'est fou cette difficulté que peuvent alors les gens pour lire une
référence.
Non, non, je t'assure que j'en bouffe pas mal depuis le debut :)
Mais en l'occurence, et d'apres la MSDN:
"Return Value
A streampos type, corresponding to a long."
Apres je n'ai pas assez de connaissances et de capacites pour
contredire la msdn ^_^
Il y a autre chose que la MSDN dans la vie !
La norme,
elle, decrit:
pos_type tellg();
sans plus d'explications.
En cherchant un peu, on trouve la definition de pos_type dans
basic_streambuf. C'est donc un type qui est dependant de l'objet que tu
manipules... (defini en traits du type caractere qui t'interesse).
Les traits par defaut te donnent effectivement streampos pour char,
wstreampos pour wchar.
streampos *peut* etre implemente par un long.
streampos *peut* etre implemente par un long.
streampos *peut* etre implemente par un long.
streampos *peut* etre implemente par un long.
Sauf que dans les en-têtes, je trouve :
typedef fpos<_Mbstatet> streampos;
C'est en fait un type classe, comme le veut la norme. Il se
convertit (implicitement) en streamoff, qui a type long. (Ce qui
me semble bizarre, parce que les longs, c'est du 32 bits, et les
fichiers sous Windows peut bien avoir plus de 2^32 octets.
Quand je fait GetFileAttributesEx, j'ai bien la taille dans le
WIN32_FIND_DATA, sur deux mots de 32 bits.)
Sauf que dans les en-têtes, je trouve :
typedef fpos<_Mbstatet> streampos;
C'est en fait un type classe, comme le veut la norme. Il se
convertit (implicitement) en streamoff, qui a type long. (Ce qui
me semble bizarre, parce que les longs, c'est du 32 bits, et les
fichiers sous Windows peut bien avoir plus de 2^32 octets.
Quand je fait GetFileAttributesEx, j'ai bien la taille dans le
WIN32_FIND_DATA, sur deux mots de 32 bits.)
Sauf que dans les en-têtes, je trouve :
typedef fpos<_Mbstatet> streampos;
C'est en fait un type classe, comme le veut la norme. Il se
convertit (implicitement) en streamoff, qui a type long. (Ce qui
me semble bizarre, parce que les longs, c'est du 32 bits, et les
fichiers sous Windows peut bien avoir plus de 2^32 octets.
Quand je fait GetFileAttributesEx, j'ai bien la taille dans le
WIN32_FIND_DATA, sur deux mots de 32 bits.)