Citation
alexkid
Bonjour,
...
Je me demande si ce n'est pas un peu lourd d'effectuer 700 lectures de
...
...
alors lire mes 700 fichiers ce serait une solution, mais bon ...

S'agit-t-il de faire 700 lectures d'un fichier ou de faire une lecture de 700 fichiers, ce n'est pas vraiment pareil.

Poste le Saturday 7 October 2006 19:18:59

700 fichiers différents

Poste le Saturday 7 October 2006 19:34:49

Aucun problème de lire séquentiellement plein de fichiers en séquence. Il faut donc en ouvrir un par fopen (qui fait un appel système open(2)) le lire, puis le refermer par fclose. On peut recommencer autant qu'on veut. Par exemple, grep -r fait ça sans problème, et si tu fais

grep -rl a /

tous les fichiers lisibles sont lus.

Par contre, il ne faut pas oublier de fermer (par fclose, ou l'appel système close(2)) les fichiers. Il est important d'en avoir peu ouverts en même temps. Autrefois, ce peu était une vingtaine, mais sur les linux récents convenablement configurés il peut atteindre le millier (voire 32000 en insistant).

De plus tu peux projeter en mémoire (par l'appel système mmap(2)) pleins de fichiers, la limitation étant la zone de swap ou l'espace d'adressage. C'est ainsi que fonctionne dlopen, et mon programme manydl.c [starynkevitch.net] disponible sur ma page [starynkevitch.net] montre qu'on peut faire des dizaines (voire centaines) de milliers de dlopen. Le corrolaire intéressant, c'est qu'on peut méta-programmer ainsi en C: depuis un programme C (prog.c compilé en prog), générer à l'exécution de prog un fichier de source C fichier.c, le compiler (par un system lançant un gcc -fPIC -shared -O fichier.c -o fichier.so) puis le charger dynamiquement par un dlopen("fichier.so", RTLD_GLOBAL); On peut recommencer en pratique beaucoup de fois (peut-être des millions de fois, sans même faire de dlclose!), la limitation sera pratiquement le temps de compilation cumulé des fichiers fichier*.c ainsi générés, et éventuellement l'espace d'adressage.





----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 7 October 2006 20:07:35

Méta-programmer en C, ce doit être très nterressant, surtout pour créer des programmes évolutionistes.

En tout cas merci pour cette réponse à la fois claire et précise. Je me permets de garder votre mail pour vous contacter ultérieurement.

Poste le Saturday 7 October 2006 20:26:33

Citation
alexkid
Méta-programmer en C, ce doit être très interressant, surtout pour créer des programmes évolutionistes.

Il y a des langages où c'est plus simple: Metaocaml [metaocaml.org] dont le typage garantit une certaine qualité [v]dans un sens techniquement précis de typage[/v] du programme généré, ou bien Common Lisp, ou même Java dont certaines bibliothèques savent générer du bytecode.

Et il y a aussi libjit ou GNU lightning qui peuvent (en C) aider à ça.

Comme vous l'imaginez, le sujet m'intéresse....


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 7 October 2006 20:33:12

A part le langage impératif, LISP, je ne connais pas les autres références que vous venez de préciser. Mais je vais de suite étudier un minimum le sujet.
Je pensais associer la programmation logique (PROLOGUE) et le concept de programmes évolutionnistes ... mais pour moi tout cela est encore flou ...

Poste le Saturday 7 October 2006 21:22:57

On peut continuer cet échange par mél [v]car ca devient un peu technique pour ce forum; nous sommes probablement les seuls intéresssés[/v]: le mien est basile@starynkevitch.net


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 7 October 2006 21:45:07

Citation
alexkid
Si je fait sizeof ou strlen ça ne peut pas marcher

strlen() c'est pour compter le nb de caractères d'une chaîne, c'est à dire le nombre de char de valeur différente de 0 qu'il y a à partir d'un pointeur de départ. Si on passe à cette fonction l'adresse d'une structure, elle comptera bravement les octets qu'il y a à partir de cette adresse jusqu'à ce qu'elle tombe sur un 0. Le résultat ne sera certainement pas celui attendu.
sizeof() marche pour les structures même composées d'autres structures et donnera le bon résultat à condition que la structure "mère" contienne bien l'intégralité de la structure "fille" et non un pointeur sur cette dernière.
Ex1:

struct s_fille {
   char tab[100];
};

struct s_mere {
    struct s_fille f;
} elem;

sizeof(elem) donnera 100

Ex2:

struct s_fille {
   char tab[100];
};

struct s_mere {
    struct s_fille *f;
} elem;

sizeof(elem) donnera 4

On retrouve un problème similaire quand on essaye de copier "elem". Avec l'exemple 2, on se retrouve avec 2 structures contenant le même pointeur sur une seule zone "s_fille"...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Saturday 7 October 2006 22:02:43

Zut, je suis dans le cas 2. Je crois que je vais céder à la faciliter, et effectuer une lecture séquentielle des 700 fichiers.

Merci beaucoup pour ces précisions.

Poste le Saturday 7 October 2006 22:33:38

Citation
alexkid
Je crois que je vais céder à la faciliter, et effectuer une lecture séquentielle des 700 fichiers

D'un point de vue algorithmique, c'est en effet plus propre. Tu programmes un algo (une fonction) qui traite un fichier, et tu appelles cette fonction pour chaque fichier que t'as à traiter. Ca rend ton algo beaucoup plus évolutif. Si demain tu n'as plus que 300 fichiers ou au contraire tu passes à 5000, la modif de ton programme sera minime. Et question "lourdeur", avec les puissances de nos machines d'aujourd'hui, tu sentiras rien.


L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Sunday 8 October 2006 13:16:02