CLASSE LECTRICE DE FICHIERS INI SANS UTILISER LES APIS

DeadlyPredator Messages postés 222 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 30 juin 2008 - 9 août 2004 à 03:29
cs_philcam Messages postés 132 Date d'inscription dimanche 12 août 2001 Statut Membre Dernière intervention 17 octobre 2008 - 22 août 2004 à 03:52
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/25267-classe-lectrice-de-fichiers-ini-sans-utiliser-les-apis

cs_philcam Messages postés 132 Date d'inscription dimanche 12 août 2001 Statut Membre Dernière intervention 17 octobre 2008
22 août 2004 à 03:52
j'aime bien entendre parler de rapidité d'accès.

Car celui qui arrive à chronométrer le temps d'accès à la base de registre et celui à un fichier *.ini, je dis bravo !

Vous travaillez avec des zx81 ou quoi ?

cela dit je reste qd meme du coté de la BDR !

J'entends d'ici les commentaires, oui mais quand tu as un programme hyper évolué, gnagnagna, ça ralentit ton prog sensiblement, gnagnagna, allez bonne nuit !
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
21 août 2004 à 22:00
Une autre aussi, le seul avantage du XML est la possibilite de le lire a travers differents systemes. A part cela c'est d'une lenteur affligeante car necessite le parsage de texte alors que la BDR est un modele indexe comme toute base de donnees et donc tres rapide d'acces.
crenaud76 Messages postés 4172 Date d'inscription mercredi 30 juillet 2003 Statut Membre Dernière intervention 9 juin 2006 28
21 août 2004 à 21:47
Jucidieuse remarque Brunews, d'autant plus que "INI" la tête en bas ca donne ...... "INI" !!!
Autre avantage pour le fichier ini : Il et bien plus simple pour un tiers de le modifier via un vulgaire notepad.exe. Faire fair eune modif en registre est un peu plus complexe, et risqué
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
17 août 2004 à 10:04
VB aura cesse d'exister bien avant la base de registres, faut pas regarder les choses la tete en bas.
capuccino_fr Messages postés 113 Date d'inscription vendredi 5 mars 2004 Statut Membre Dernière intervention 11 février 2008
17 août 2004 à 09:59
car la base de registre n'existera plus d'ici quelques annees. c'est deja une bonne raison !!
et puis la base de registre c'est au moins aussi long a traiter qu'un pauvre petit fichier INI.

mais le top, c'est le XML pour conserver des donnees d'une appli, avec les classes existantes: rapide, efficace, peut etre utilisé par d'autres appli.

affaire a suivre. @+
cs_philcam Messages postés 132 Date d'inscription dimanche 12 août 2001 Statut Membre Dernière intervention 17 octobre 2008
16 août 2004 à 19:03
Salut,

désolé je vais faire un commentaire pas très constructif mais j'ai reçu cette source dans le mail du mois.

Pourquoi se faire chier avec les fichiers *.ini, puiqu'il y a la base de registre ?

Les fichiers *.ini ça fait un peu vieillot non ?

@+
crenaud76 Messages postés 4172 Date d'inscription mercredi 30 juillet 2003 Statut Membre Dernière intervention 9 juin 2006 28
10 août 2004 à 08:53
Une question et deux remarques !
Question : Qu'est-ce que c'est que ce DllFunctionCall dont tu parles dans le cas des API ???
Remarque 1 : Je n'ai jamais vu un INI avec 60 000 sections !! Il faut savoir qu'un fichier INI est censé être modifiable "à la main" via notepad. Si un éditeur de soft me pond un INI avec 60 000 section, je lui balance son soft à la tronche et je vais voir la concurrence !!
Remarque 2 : La taille limite pour une chaine de longueur variable est d'environ 2 milliards de caractères, ce qui avec 9 caractères par section (10 avec le vbNullChar) te fait une bagatelle de 200 millions de sections !!!!!!!!!!!!! Et Oui !! 200 millions !!!!
DeadlyPredator Messages postés 222 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 30 juin 2008
10 août 2004 à 07:14
Pour windows Nt, je trouve que ça a l'air interessant. Bon je vais révèller ma prochaine source : un API viewer qui va devoir contenir beaucoup d'APIs (va devoir être prêt à supporte 60 000+ sections). Et le type string à une limite je crois. Même si tu a 1 go de RAM, on s'en fiche car la taille variable buffer à une limite. Tu vois tu 60 000 sections (avec des noms d'au moins 4 caractères) dans un string séparés par un nullstring : 300000 octets donc 0.28 mo juste pour ça! En plus, il faut splitter le string
col=split((300000 octets),chr(0))'Un array de 60 000 c'est gros
For i = 0 to ubound(col)
...
next

En parlant pour les APIs, sous l'IDE c'est vite car note code vb est lent alors que l'API est déjà compilée. Mais essais une fois compillé quand le code est compilé en natif et qu'il est bien plus rapide... l'API perd ça vitesse à cause de DllFunctionCall
crenaud76 Messages postés 4172 Date d'inscription mercredi 30 juillet 2003 Statut Membre Dernière intervention 9 juin 2006 28
9 août 2004 à 21:25
Il faudrait faire des tests, mais comme brunews, je reste persuader que les API seront touours plus rapide, et moins gourmande en ressource système (Memoire et tps CPU) qu'une classe écrite en VB.
De plus par rapport à l'obsolescence de ces API du fait de l'existance de la registry Windows, voici ce que dit le MSDN pour GetprivateProfileSection :

Windows NT: Calls to private profile functions may be mapped to the registry instead of to the specified initialization files. This mapping occurs when the initialization file and section are specified in the registry under the following keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\
Windows NT\CurrentVersion\IniFileMapping

This mapping is likely if an application modifies system-component initialization files, such as CONTROL.INI, SYSTEM.INI, and WINFILE.INI. In these cases, the GetPrivateProfileSection function retrieves information from the registry, not from the initialization file; the change in the storage location has no effect on the function's behavior.
De plus, tu dis ceci : " avec l'API par exemple, quand on veut énumérer les sections, on est oubligé de TOUT mettre dans un variable string." ... dis-moi exactement combien tu as déjà au maximum de section dans un fichier Ini ? et combien d'octet cela représenterait-il en mémoire ? Combien de % cela fait sur les 1 Go de RAM de ma sation ? Même si ta machine n'a que 256 Mo de Ram, ca fait combien, honnêtement ? Et combien de place prend ta classe en mémoire ? Fait bien le calcul et tu verras que tu dois pas être bien loin du compte !!
DeadlyPredator Messages postés 222 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 30 juin 2008
9 août 2004 à 16:21
Et j'oubliais, si j'ai écrit ça, c'est un peu pour me pratiquer pour ouvrir des fichiers sans FSO ni avec les APIs createfile...
DeadlyPredator Messages postés 222 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 30 juin 2008
9 août 2004 à 16:20
Bon là, j'ai une grosse question : Une API, est-ce que ç'est vraiment vite si VB l'appelle indirectement via DLLFunctionCall ... au contraire du CPP qui appelle directement. Cette classe offre quelque chose QUI NE SURCHARGE PAS la mémoire : avec l'API par exemple, quand on veut énumérer les sections, on est oubligé de TOUT mettre dans un variable string. Avec ma source, chaque section est envoyée via un évènement et en plus, on arrête l'énumération quand on veut... n'oublions pas que les APIs pour les Inis sont considérés comme discontinués car elles ne sont là que pour la compatibilitée avec les programmes 16 Bits. Les programmes d'aujourd'hui devraient écrire les config dans le registre selon microsoft MAIS un registre, est ce que ça peut voyager dans un zip sans être oubligé d'utiliser regedit et de façon à ce que le système ne risque pas d'être d'endommagé par un fichier reg contenant du code mal intentionné?
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
9 août 2004 à 10:13
Je dis que tu peux meme etre certain que ce sera enormement plus lent que par API. On ne reecrit jamais ce que le systeme propose deja car son code en kernel mode ira toujours plus vite que le notre, fut-il ecrit en natif compile. Alors ici en interprete....
DeadlyPredator, la tentative est louable mais vaine.
crenaud76 Messages postés 4172 Date d'inscription mercredi 30 juillet 2003 Statut Membre Dernière intervention 9 juin 2006 28
9 août 2004 à 09:10
Ben tu m'excuseras mais je préfère, et de très loin travailler avec les API !!. Je n'ai malheureusement pas le temps de tester ton code, mais cela me parait bien dommage de réinventer une classe, alors que les API sont la pour cela. Et je suis pas certain du tout que ce soit plus rapide que les appels API sur des gros fichiers INI.
DeadlyPredator Messages postés 222 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 30 juin 2008
9 août 2004 à 05:24
Nouvelle source. À la place des 4 fonctions répétitives, j'en ai fait 1 qui lit le fichier, 1 qui dit quoi faire avec une section et une qui dit quoi faire avec un clef. Je vais sûrement faire d'autres changements
DeadlyPredator Messages postés 222 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 30 juin 2008
9 août 2004 à 03:29
Le problème, ça va être l'écriture. Cette tâche est beaucoup plus complexe... car il va falloir charger le fichier en mémoire, trouver la section/clef à changer/supprimer, effectuer la modification et enregistrer mais le but de cette source est de pouvoir traiter un TRÈS gros fichier ini donc il faut oublier le chargement en mémoire. Est-ce que quelqu'un s'il y a une procédure déjà dans les Dlls de VB qui permet de renommer les fichiers (pas copier pi supprimer l'original car ça serait un perte de temps)?

Je crois qu'il y aurait moyen d'optimiser grandement l'espace de ce code. Les 3 grosses procédures se ressemblent. Je vais changer la structure.