Bonjour,
Je m'explique.
J'ai des classes qui disposent d'une méthode
void Read(std::istream& input)
et je voudrais savoir s'il est possible de lire directement une portion de
fichier connue dans un stringstream pour la soumettre à ces méthodes
Quand on se retrouve avec tant de "std::" dans la même ligne, c'est signe qu'il faut mettre un "using namespace std;" au début de la fonction.
[...] std::stringstream input(s); s.clear();
J'écrirais plutôt "istrinstream input (s);" sans le "clear()".
puis obj.Read(input);
J'admets que ça fait beaucoup de copies dans tous les sens. Est-ce vraiment gênant ? Ne peux-tu pas "ranger" ce code inélégant dans une fonction à part, histoire que tout soit bien propre ?
Je vois bien une solution pour éviter toutes ces copies, mais je suis absolument incapable de prévoir si le programme ira plus ou moins vite.
La solution en question est de créer ton propre istream, avec ton propre streambuf, qui se contente de passer les ordres à mainfile.rdbuf(), tout en arrêtant la lecture au bout de "len" caractères. Je ne me suis jamais vraiment attaqué à ces méthodes, du coup je ne suis pas forcément de bon conseil.
Mais d'une manière générale, rappelle-toi la règle d'or du programmeur : "if it ain't broke, don't fix it".
On Sun, 7 Sep 2008 14:39:32 +0200, "Marc G" <mgueguen@metrica.fr>:
Quand on se retrouve avec tant de "std::" dans la même ligne, c'est
signe qu'il faut mettre un "using namespace std;" au début de la
fonction.
[...]
std::stringstream input(s);
s.clear();
J'écrirais plutôt "istrinstream input (s);" sans le "clear()".
puis
obj.Read(input);
J'admets que ça fait beaucoup de copies dans tous les sens.
Est-ce vraiment gênant ?
Ne peux-tu pas "ranger" ce code inélégant dans une fonction à part,
histoire que tout soit bien propre ?
Je vois bien une solution pour éviter toutes ces copies, mais je suis
absolument incapable de prévoir si le programme ira plus ou moins
vite.
La solution en question est de créer ton propre istream, avec ton
propre streambuf, qui se contente de passer les ordres à
mainfile.rdbuf(), tout en arrêtant la lecture au bout de "len"
caractères.
Je ne me suis jamais vraiment attaqué à ces méthodes, du coup je ne
suis pas forcément de bon conseil.
Mais d'une manière générale, rappelle-toi la règle d'or du
programmeur : "if it ain't broke, don't fix it".
Quand on se retrouve avec tant de "std::" dans la même ligne, c'est signe qu'il faut mettre un "using namespace std;" au début de la fonction.
[...] std::stringstream input(s); s.clear();
J'écrirais plutôt "istrinstream input (s);" sans le "clear()".
puis obj.Read(input);
J'admets que ça fait beaucoup de copies dans tous les sens. Est-ce vraiment gênant ? Ne peux-tu pas "ranger" ce code inélégant dans une fonction à part, histoire que tout soit bien propre ?
Je vois bien une solution pour éviter toutes ces copies, mais je suis absolument incapable de prévoir si le programme ira plus ou moins vite.
La solution en question est de créer ton propre istream, avec ton propre streambuf, qui se contente de passer les ordres à mainfile.rdbuf(), tout en arrêtant la lecture au bout de "len" caractères. Je ne me suis jamais vraiment attaqué à ces méthodes, du coup je ne suis pas forcément de bon conseil.
Mais d'une manière générale, rappelle-toi la règle d'or du programmeur : "if it ain't broke, don't fix it".
Marc G
> La solution en question est de créer ton propre istream, avec ton propre streambuf, qui se contente de passer les ordres à mainfile.rdbuf(), tout en arrêtant la lecture au bout de "len" caractères. Je ne me suis jamais vraiment attaqué à ces méthodes, du coup je ne suis pas forcément de bon conseil.
en comparant les vitesses d'exécution entre une lecture directe via les API Win32 et les méthodes de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à 20 environ) Peut-être que je ne sais pas bien paramétrer l'utilisation des stream.. => finalement, je me suis créé ma propre classe CBuffer pour lire et écrire dans les fichiers en utilisant un tampon. J'y ai mis le minimum nécessaire lié à l'utilisation que j'en fais, et ça va beaucoup plus vite...
Merci de ta réponse. Marc
> La solution en question est de créer ton propre istream, avec ton
propre streambuf, qui se contente de passer les ordres à
mainfile.rdbuf(), tout en arrêtant la lecture au bout de "len"
caractères.
Je ne me suis jamais vraiment attaqué à ces méthodes, du coup je ne
suis pas forcément de bon conseil.
en comparant les vitesses d'exécution entre une lecture directe via les API
Win32 et les méthodes
de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à
20 environ)
Peut-être que je ne sais pas bien paramétrer l'utilisation des stream..
=> finalement, je me suis créé ma propre classe CBuffer pour lire et écrire
dans les fichiers en utilisant un tampon.
J'y ai mis le minimum nécessaire lié à l'utilisation que j'en fais, et ça va
beaucoup plus vite...
> La solution en question est de créer ton propre istream, avec ton propre streambuf, qui se contente de passer les ordres à mainfile.rdbuf(), tout en arrêtant la lecture au bout de "len" caractères. Je ne me suis jamais vraiment attaqué à ces méthodes, du coup je ne suis pas forcément de bon conseil.
en comparant les vitesses d'exécution entre une lecture directe via les API Win32 et les méthodes de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à 20 environ) Peut-être que je ne sais pas bien paramétrer l'utilisation des stream.. => finalement, je me suis créé ma propre classe CBuffer pour lire et écrire dans les fichiers en utilisant un tampon. J'y ai mis le minimum nécessaire lié à l'utilisation que j'en fais, et ça va beaucoup plus vite...
Merci de ta réponse. Marc
Fabien LE LEZ
On Mon, 8 Sep 2008 11:44:25 +0200, "Marc G" :
en comparant les vitesses d'exécution entre une lecture directe via les API Win32 et les méthodes de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à 20 environ)
Quel compilateur utilises-tu ? J'ai moi aussi constaté de tels écarts, mais avec un très vieux compilo (Borland C++ 5.02).
On Mon, 8 Sep 2008 11:44:25 +0200, "Marc G" <mgueguen@metrica.fr>:
en comparant les vitesses d'exécution entre une lecture directe via les API
Win32 et les méthodes
de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à
20 environ)
Quel compilateur utilises-tu ?
J'ai moi aussi constaté de tels écarts, mais avec un très vieux
compilo (Borland C++ 5.02).
en comparant les vitesses d'exécution entre une lecture directe via les API Win32 et les méthodes de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à 20 environ)
Quel compilateur utilises-tu ? J'ai moi aussi constaté de tels écarts, mais avec un très vieux compilo (Borland C++ 5.02).
Marc G
j'utilise CPP Builder 2007 mais je ne crois pas que le compilateur soit en cause, plutôt éventuellement la version de la stl implémentée. Quand je regarde le code de la stl, je comprends un peu pourquoi ça rame. Franchement, quand la vitesse de lecture est importante, il est préférable de gérer soit même les opérations de lecture/écriture, d'autant que ce n'est pas la partie la plus obscure de windows :-) La classe de buffer que j'ai écrite n'est pas extraordinaire, mais en moins de 100 lignes de code, elle fait ce qu'elle a a faire...
"Fabien LE LEZ" a écrit dans le message de news:
On Mon, 8 Sep 2008 11:44:25 +0200, "Marc G" :
en comparant les vitesses d'exécution entre une lecture directe via les API Win32 et les méthodes de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à 20 environ)
Quel compilateur utilises-tu ? J'ai moi aussi constaté de tels écarts, mais avec un très vieux compilo (Borland C++ 5.02).
j'utilise CPP Builder 2007
mais je ne crois pas que le compilateur soit en cause, plutôt éventuellement
la version de la stl implémentée.
Quand je regarde le code de la stl, je comprends un peu pourquoi ça rame.
Franchement, quand la vitesse de lecture est importante, il est préférable
de gérer soit même les opérations de lecture/écriture,
d'autant que ce n'est pas la partie la plus obscure de windows :-)
La classe de buffer que j'ai écrite n'est pas extraordinaire, mais en moins
de 100 lignes de code,
elle fait ce qu'elle a a faire...
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:r80ac49798pdc2qln3lffbddaqt7qniuo0@4ax.com...
On Mon, 8 Sep 2008 11:44:25 +0200, "Marc G" <mgueguen@metrica.fr>:
en comparant les vitesses d'exécution entre une lecture directe via les
API
Win32 et les méthodes
de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1
à
20 environ)
Quel compilateur utilises-tu ?
J'ai moi aussi constaté de tels écarts, mais avec un très vieux
compilo (Borland C++ 5.02).
j'utilise CPP Builder 2007 mais je ne crois pas que le compilateur soit en cause, plutôt éventuellement la version de la stl implémentée. Quand je regarde le code de la stl, je comprends un peu pourquoi ça rame. Franchement, quand la vitesse de lecture est importante, il est préférable de gérer soit même les opérations de lecture/écriture, d'autant que ce n'est pas la partie la plus obscure de windows :-) La classe de buffer que j'ai écrite n'est pas extraordinaire, mais en moins de 100 lignes de code, elle fait ce qu'elle a a faire...
"Fabien LE LEZ" a écrit dans le message de news:
On Mon, 8 Sep 2008 11:44:25 +0200, "Marc G" :
en comparant les vitesses d'exécution entre une lecture directe via les API Win32 et les méthodes de la STL, je trouve des écarts d'efficacité "hallucinants" (rapport de 1 à 20 environ)
Quel compilateur utilises-tu ? J'ai moi aussi constaté de tels écarts, mais avec un très vieux compilo (Borland C++ 5.02).
Fabien LE LEZ
On Mon, 8 Sep 2008 15:12:20 +0200, "Marc G" :
Note : merci d'écrire en français, c'est-à-dire, de haut en bas.
j'utilise CPP Builder 2007 mais je ne crois pas que le compilateur soit en cause, plutôt éventuellement la version de la stl implémentée.
C'est fort possible. Comme je l'ai dit, j'ai pu constater que BC++ 5.02 était très mauvais de ce côté, et comme Borland a plus ou moins abandonné le C++, il est possible qu'ils n'aient pas amélioré leur bibliothèque standard.
Il serait intéressant de tester ton code (avec iostream) sur un compilo moderne comme g++ 4.x ou Visual C++ 2008 express (tous deux gratuits).
On Mon, 8 Sep 2008 15:12:20 +0200, "Marc G" <mgueguen@metrica.fr>:
Note : merci d'écrire en français, c'est-à-dire, de haut en bas.
j'utilise CPP Builder 2007
mais je ne crois pas que le compilateur soit en cause, plutôt éventuellement
la version de la stl implémentée.
C'est fort possible. Comme je l'ai dit, j'ai pu constater que
BC++ 5.02 était très mauvais de ce côté, et comme Borland a plus ou
moins abandonné le C++, il est possible qu'ils n'aient pas amélioré
leur bibliothèque standard.
Il serait intéressant de tester ton code (avec iostream) sur un
compilo moderne comme g++ 4.x ou Visual C++ 2008 express (tous deux
gratuits).
Note : merci d'écrire en français, c'est-à-dire, de haut en bas.
j'utilise CPP Builder 2007 mais je ne crois pas que le compilateur soit en cause, plutôt éventuellement la version de la stl implémentée.
C'est fort possible. Comme je l'ai dit, j'ai pu constater que BC++ 5.02 était très mauvais de ce côté, et comme Borland a plus ou moins abandonné le C++, il est possible qu'ils n'aient pas amélioré leur bibliothèque standard.
Il serait intéressant de tester ton code (avec iostream) sur un compilo moderne comme g++ 4.x ou Visual C++ 2008 express (tous deux gratuits).
