RHJPP (./41) :
En fait, la méthode consistant à passer une fonction à appliquer à chaque entrée de la liste est intéressante, mais les performances pourraient en pâtir.

- pourraient en pâtir + en patiront certainement.

RHJPP (./41) :
Par exemple, je suppose que l'archive contient directement le nombre de fichiers archivés

Oui, sur deux octets, pourquoi s'en priver. D'autant plus que si on n'utilise pas ça, il faut un marqueur de fin, donc au final on ne gagne pas en place.

RHJPP (./41) :
Par exemple, je ne sais pas comment sont organisés tes fichiers, si dans une hypothétique table des matières ils sont triés par nom ou pas, mais si c'était le cas, une recherche dichotomique serait bien plus rapide pour trouver un fichier que de parcourir toute la liste.

Non, c'est une archive, pas une base de données. Même parcourir 200 fichiers, en asm et optimisé (pas de fonctions strcmp etc..., mais tout à la main (ça prend pas de place), c'est très rapide. Et le passage d'une entrée à l'autre est une simple addition. Donc je ne me fais pas de souci pour trouver vite un fichier, même au bout de l'archive.

RHJPP (./41) :
- On cherche des infos sur un fichier dont on connaît le nom => Utilisation de la fonction par__FileInfo - On veut quelque chose concernant un fichier dont on ne connaît pas le nom => Parcours avec une boucle for du tableau retourné par par__List. Ce sera bien plus rapide que d'utiliser une autre méthode.

Je pense aussi. Et autant laisser le programme faire ça, la lib n'est pas censée savoir ce que le programme recherche, et ne peut prévoir tous les cas. Au final, elle ne fournirait pas une très grande aide. AMHA le programme a déjà tout ce qu'il lui faut dans un listing.

RHJPP (./41) :
Après, si par exemple le contenu du fichier devenait accessible à la fonction à appliquer, ce serait peut-être bien de le faire. Mais bon, il ne s’agirait probablement que d'un pointeur à ajouter à la structure d'information

Et j'ai pas envie de le faire. Ca nécessite de locker l'archive. Hors je la fais bouger si, par exemple, on me dit d'y rajouter un fichier et que l'archive est en flash. C'est automatique, et le caller n'est pas censé savoir que ça va arriver, à part s'il refait le boulot de localiser l'archive et de regarder où elle est ; ça fait double emploi avec la lib qui la décharge de ce boulot : une simple C-string suffit à accéder à une archive. Un de mes buts est de rendre l'archive accessible avec un minimum de travail pour le caller.

J'ai relu il y a quelques jours tous les headers des libs d'archive/compression existantes sur TI, chaque fois une grosse part est laissée à faire au programme, et j'aime pas beaucoup ça. Pour moi, deux programmes utilisant la même lib ne devraient pas dupliquer de code.