Discussion :

[Luc Hermitte]

Bonsoir, Luc, (je ne savais pas si on pouvait se tutoyer ;-))

Sur le net, j'ai vraiment du mal avec le vouvoyement. Ca fait trop bizarre.

Généralement je préfère lire des fichiers pdf valides, ça facilite la lecture ;-) blague à part c'est vrai que si le fichier est pourri, la lecture le sera aussi!

Je disais juste ça pour éviter le coredump.

Là je ne vois pas trop ce que tu entends par 'blocs', je ne cherche pas à trouver tous les '%%EOF' du fichier mais seulement le dernier, mais si tu as un exemple sous la main, je veux bien tester.

Ben par bloc de 512 ou autre qui soit efficace sur ton systême. Je ne suis pas un pro des optims fichiers, mais j'en suis toujours resté au fait que la lecture caractère par caractère n'était pas efficace. Par contre, pour lire par blocs, il va falloir renverser ce que tu lis, ou faire des push_front.
Hum... je vois que deque ne sait pas les faire par bloc Du coup il faudrait une liste de vecteurs (une deque gérée à la main quoi) avec une fonction spécialisée pour la recherche. cool.
En pseudo code pondu en direct, et buggué, cela donnerait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
std::list<std::vector<char> > buffers;
int buf_size = 512;
 
for( int pos = file_length - buf_size
    ; buf_size != 0
    ; buf_size -= min(512,pos), pos -= buf_size) // va certainement planter => faire un while
{
    buffers.push_front(std::vector<char>());
    buffers.front().resize(buf_size);
    if(! file . read( &buffers.front()[0], buf_size)) break;
    if ( found(buffers) ) break;
}

Pour la mémoire, c'est vrai, je ne m'en préoccupe pas trop, je pensais que 'vector.push_back(qqch)' s'en chargeait, mais je me trompe peut-être. Mais allouer une chaine de caratères de la taille du fichier (comme limite) est une solution.

C'est juste pour éviter une 10aines d'allocations.

Je pense avoir vu quelque chose pour améliorer le traitement sur la chaine, faut que je regarde si ça marche bien avec 'vector'.

Pour optimiser, je crains qu'il faille implémenter ta propre fonction de recherche un peu particulière : un strcmp qui utilise un -- au lieu d'un des deux ++.

[JµL!eN]

Je ne cherchais pas à faire quelque chose d'aussi compliqué que ça (deque ou liste de vector).

Pour la lecture, comme je sais que ce que je dois chercher se trouve plus près de la fin que du début (en général), pourquoi ne pas lire le fichier à partir de la fin directement? Partir du début serait un traitement général. Je peux lire à partir de la fin en mode binaire, en faisant gaffe à la taille de mon fichier.

Pour la mémoire, c'est vrai, je ne m'en préoccupe pas trop, je pensais que 'vector.push_back(qqch)' s'en chargeait, mais je me trompe peut-être. Mais allouer une chaine de caratères de la taille du fichier (comme limite) est une solution.

C'est juste pour éviter une 10aines d'allocations.

L'allocation se faisait pour chaque caractère qui devait être lu, il n'y a pas d'allocation en trop; l'affectation par le '.push_back' (donc l'allocation) se fait normalement ? Il y a tout au plus 3 ou 4 allocations de trop pour 'EOF' ou '%EOF' ;-)

Je regarderais le code que tu as esquissé plus tard (ou plus tôt ;-) ). Je regarderais aussi la lecture binaire en partant de la fin. Je n'arrive pas à voir comment parvenir à déchiffrer '%EOF' en binaire, peut-être parce qu'il est tard ;-)

@+

[Luc Hermitte]

A partir de la fin caractère par caractère, je crains que tu fasses plus d'accès disques que nécessaire. D'où que j'évoquais la bufferisation.

"Accès binaire" porte moyennement bien son nom. "raw" aurait peut-être été meilleur, je ne sais pas.
L'ouveture binaire signifie juste que certains caractères ne seront plus interprétés. Et que donc, cela sera à toi de savoir comment est codée une fin de ligne, ...
"%%eof" reste "%%eof". C'est toujours la même chaine qu'il faut chercher.