squalyl (./37) :
je trouve très pas bien du tout que la lib alloue des handles comme dit avant. On est en embarqué, la mémoire est "chère", je veux controler comment elle est allouée. je pense que ce serait 10 fois plus mieux bien de passer un handle de bonne taille à ta lib pour qu'elle le remplisse, puisque la taille du bidule est connue. Au moins l'utilisateur a le controle de l'allocation de A à Z alloc à free.

Je comprends bien, mais on est quand même en embarqué, donc au final, pourquoi ne pas centraliser ce boulot dans la lib (niveau place) ? Et de toute façon, cette mémoire sera allouée.
Je comprends que ça puisse être plus joli niveau concept, mais je ne crois pas qu'on gagne quelque chose en efficacité réelle.

squalyl (./37) :
soit tu files un callback à une fonction style par__EnumerateFiles(type_fn_callback the_callback, void *contexte), qui a la responsabilité d'appeler ta fonction callback pour chaque fichier en lui passant les infos sur ce fichier et le contexte (pour pouvoir relier tous les appels -- plus de détails dans un prochain post si ça t'intéresse

Oui, ça m'intéresse.
Si je comprends bien, plutôt que le caller dise à la lib "tu fais ça", il dit "lis-moi cette archive" ; "ok, premier fichier c'est ça" ; "ok, tu fais rien" ; "2nd fichier..." ; "ah là, tu désarchives" ; etc...
C'est ça ?

Ca me semble un peu chiant niveau perf, pour chaque occurence de fichier trouvé par la lib, le caller va devoir parcourir sa propre liste de fichiers pour savoir ce qu'il doit faire du fichier en question.

Je ne sais pas pourquoi, mais ça me fait penser à des architectures de langage de beaucoup plus haut niveau. Ton habitude du Java peut-être ?

squalyl (./37) :
-soit une fonction par__listFirst(blabla) qui te renvoie les infos sur le premier fichier de la lib, et un par__listNext(blabla) qui te renvoie à chaque coup les infos sur le fichier suivant. On peut avoir une structure de "contexte" qui se souvient d'ou on en est, ou stocker ça en interne.

Alors dans ce genre de cas, ça sera au programme de stocker ça (lib read-only powa). Comme mes fonctions pour gérer les arguments, les programmes passent une structure CMDLINE* à ma lib.
Puisqu'on est read-only, on ne peut rien retenir. Et c'est pour ça que mes fonctions utilisent beaucoup des callbacks également, pour ne pas perdre le boulot en cours.


Sinon, ça revient en fait à énumérer, mais sans callback, donc avec le problême cité au-dessus (perf).
En fait, ma première version de lib pour parser la ligne de commande faisait comme ton énumérateur. Beaucoup de code à écrire par le programme, c'était absolument pas rentable. La version actuelle ressemble beaucoup plus à ta proposition du dessus (avec callback). C'est beaucoup plus facile à gérer pour la ligne de commande, parce que la lib sait d'elle-même quoi faire avec les switches. Le programme en lui-même ne s'occupe que des arguments qui n'en sont pas (et donc a priori, des fichiers).
Je crains que ce ne soit guère efficace pour cette situation, mais je veux bien que tu détailles si j'ai mal compris.

squalyl (./37) :
tu peux aussi m'envoyer bouler et faire comme tu veux, je m'offusquerai pas

Mais pas du tout, bien au contraire, je suis mauvais en spec, je ne demande pas mieux que des avis et conseils jsutement (bon, évidemment, même si je pourrai pas tout suivre hein )