BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019
-
7 août 2005 à 10:12
NitRic
Messages postés402Date d'inscriptionmardi 1 mai 2001StatutMembreDernière intervention15 août 2011
-
24 août 2005 à 02:38
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
pour de gros fichier, c'est très pratique
avec de petit fichier, j'suis d'accord, ce n'est pas plus rapide ...
mais, il n'y à pas de ReadFile() après avoir «mappé» le fichier, t'en vois un toi?
~(.:: NitRic ::.)~
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 17 août 2005 à 09:40
Le FileMapping n'entre pour rien dans l'affaire quand il s'agit de rechercher une chaine, il faudra dans tous las cas aspirer les octets du fichier pour faire la recherche. Qu'on appelle ReadFile explicitement ou que soit fait en interne par le filemap ne changera rien.
La source dont j'ai donné le lien plus haut a bien sur été testée sur d'énormes fichiers (BDD) et résultat quasi instantané.
NitRic
Messages postés402Date d'inscriptionmardi 1 mai 2001StatutMembreDernière intervention15 août 2011 17 août 2005 à 01:18
Si j'ai le choix entre utiliser ReadFile() et lire block/block les fichiers pour rechercher une simple chaine et utiliser le FileMapping, désolé mais je choisis le FileMapping ou encore les sparsefiles, il parrait que c'est bien les sparsefiles ... Personnellement je ne me vois pas du tout faire des ReadFile()'s par centaines dans de gros fichiers, genre 500mo+, voir même 1gig+, etc ... Si vous préférez la méthode avec ReadFile() alors c'est votre choix, good luck ...
~(.:: NitRic ::.)~
jprozorback
Messages postés31Date d'inscriptionlundi 9 août 2004StatutMembreDernière intervention28 mars 2006 12 août 2005 à 21:06
moi je suis d'accord avec BruNews sachant que toute fonction utilise du code précompilé de windows, autant utiliser un methode windows, ou alors changer de system dont je crois qui est une bonne résolution, vue la stabilité de ce windows ^^
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 11 août 2005 à 22:04
API native, ReadFile lui refile le bébé.
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 11 août 2005 à 21:43
Quid de ZwReadFile?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 11 août 2005 à 21:40
NitRic > t'as fumé ???
Nimporte quelle bibli que tu emploieras en compilant pour Windows finira par un appel ReadFile en ce qui concerne la lecture de fichier, il n'y a aucun autre point d'entrée (à part l'API native mais une bibli n'y touchera jamais). ReadFile est ce qui se fait de plus rapide, ça file direct au driver qui aspire les octets, toute autre méthode est obligatoirement plus lente.
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 11 août 2005 à 21:30
ReadFile n'est pas une fonction de recherche, j'ai pas trop compris la...
NitRic
Messages postés402Date d'inscriptionmardi 1 mai 2001StatutMembreDernière intervention15 août 2011 11 août 2005 à 21:21
ReadFile() pour effectuer des recherchent
dans des fichiers??? T'as un problème dans
ta tête ou quoi!?!?!?!?! Non merci!!!
J'veux pas attendre des heures pour avoir
_Un_ résultat! :}
Au fait, je ne parlais pas de la propreté
du code mais plutôt de sa stabilité/rapidité/fiabilité/...
Sur ce, bye bye && @++; :-)
~(.:: NitRic ::.)~
jprozorback
Messages postés31Date d'inscriptionlundi 9 août 2004StatutMembreDernière intervention28 mars 2006 11 août 2005 à 00:40
ben décidement il vous plait pas mon prog , c'est vraix ke le code nengine n'est pas du plus propre ..
quand a NitRic , tu peux revoir ton algo de recherche dans les fichier on alors ten remettre la fonction de crosoft "ReadFile".
NitRic
Messages postés402Date d'inscriptionmardi 1 mai 2001StatutMembreDernière intervention15 août 2011 10 août 2005 à 15:18
Bonjour, je viens de voir mon source, nengine .... pas très jolie à voir ... alors j'ai décider de le refaire, donc JPROZORBACK, si cela t'interesse, il sera bientôt disponible, une semaine ou deux.
Sur ce, bye bye && @++;
~(.:: NitRic ::.)~
jprozorback
Messages postés31Date d'inscriptionlundi 9 août 2004StatutMembreDernière intervention28 mars 2006 7 août 2005 à 17:29
ok, merci pour l'info ;-)
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 7 août 2005 à 14:05
Tout en haut tu as un lien "ceci est votre source, cliquer ici pour mettre à jour", tu cliques et tu peux indiquer un nouveau zip, etc... Note aussi le pourquoi de la MAJ.
jprozorback
Messages postés31Date d'inscriptionlundi 9 août 2004StatutMembreDernière intervention28 mars 2006 7 août 2005 à 13:43
ce ve dire koi ca ?
j'avourai ke j'ai un peu bacler les test du programme, parcontre je ne sais pas comment on fait pour mettre a jour une source ????
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 7 août 2005 à 12:12
ben heureusement qu'il trouve.
jprozorback
Messages postés31Date d'inscriptionlundi 9 août 2004StatutMembreDernière intervention28 mars 2006 7 août 2005 à 11:59
24 août 2005 à 02:38
DWORD filesize = GetFileSize(..., ...);
/* ... */
void * mapptr = MapViewOfFile(...);
void * ptr = mapptr;
/* ici, «ptr» peu être géré comme une simple chaine de caractère(d'une certaine facon) */
/* perso, je ne vois aucun ReadFile() ici ... */
for (...; [xxx] < filesize; ...)
{
if (memcmp(ptr, ..., ...) == 0)
{
return [trouvé];
}
ptr = (BYTE *)ptr + 1;
}
/* ... */
pour de gros fichier, c'est très pratique
avec de petit fichier, j'suis d'accord, ce n'est pas plus rapide ...
mais, il n'y à pas de ReadFile() après avoir «mappé» le fichier, t'en vois un toi?
~(.:: NitRic ::.)~
17 août 2005 à 09:40
La source dont j'ai donné le lien plus haut a bien sur été testée sur d'énormes fichiers (BDD) et résultat quasi instantané.
17 août 2005 à 01:18
~(.:: NitRic ::.)~
12 août 2005 à 21:06
11 août 2005 à 22:04
11 août 2005 à 21:43
11 août 2005 à 21:40
Nimporte quelle bibli que tu emploieras en compilant pour Windows finira par un appel ReadFile en ce qui concerne la lecture de fichier, il n'y a aucun autre point d'entrée (à part l'API native mais une bibli n'y touchera jamais). ReadFile est ce qui se fait de plus rapide, ça file direct au driver qui aspire les octets, toute autre méthode est obligatoirement plus lente.
11 août 2005 à 21:30
11 août 2005 à 21:21
dans des fichiers??? T'as un problème dans
ta tête ou quoi!?!?!?!?! Non merci!!!
J'veux pas attendre des heures pour avoir
_Un_ résultat! :}
Au fait, je ne parlais pas de la propreté
du code mais plutôt de sa stabilité/rapidité/fiabilité/...
Sur ce, bye bye && @++; :-)
~(.:: NitRic ::.)~
11 août 2005 à 00:40
quand a NitRic , tu peux revoir ton algo de recherche dans les fichier on alors ten remettre la fonction de crosoft "ReadFile".
10 août 2005 à 15:18
Sur ce, bye bye && @++;
~(.:: NitRic ::.)~
7 août 2005 à 17:29
7 août 2005 à 14:05
7 août 2005 à 13:43
j'avourai ke j'ai un peu bacler les test du programme, parcontre je ne sais pas comment on fait pour mettre a jour une source ????
7 août 2005 à 12:12
7 août 2005 à 11:59
7 août 2005 à 11:50
7 août 2005 à 11:02
7 août 2005 à 10:46
7 août 2005 à 10:12
autre exemple ici:
http://www.cppfrance.com/code.aspx?ID=19169