Modifier le contenu d'un fichier

[Romu']

Bonjour,
je fais une petite introduction et après j'expose le "problème".

Je souhaite créer une simple API qui fait l'interface entre un fichier au format INI (je devrais plutôt dire "un fichier dans *un* des formats INI vu que ça n'a pas l'air normalisé ou quoi que ce soit) et un programme.

Lors de l'initialisation, le fichier .ini donné est ouvert et ce module crée et rempli une structure de données, image du contenu du fichier. Les commentaires ne sont pas recopiés car inutiles au programme. Ensuite le fichier est fermé et le programme travaille sur la structure de données.

Le "problème" :
Arrive ensuite le moment où les modifications doivent être reportées dans le fichier. Le problème est que je ne peux pas simplement ouvrir le fichier en mode w et y formater le contenu de ma structure de données, car comme les commentaires potentiellement présents n'apparaissent pas dans cette structure, ils seraient perdus.
La seule idée qui m'est venue est la suivante :

• Ouvrir le fichier .ini original en lecture.
  
• Créer un fichier temporaire ( tmpfile() ) et le remplir en croisant les informations de la structure de données (sections, variables et leur valeur) avec le contenu du fichier .ini original (commentaires).
  
• Ouvrir le fichier original en mode w et y recopier le contenu du fichier temporaire.
  

Comme ça me paraît assez lourd je me demande si je ne suis pas passé à côté d'une méthode plus simple pour modifier le contenu d'un fichier à un endroit quelconque et avec des données d'une longueur quelconque (et tout cela de manière portable) ?

Merci d'avance ;).

P.S. : je ne suis volontairement pas allé voir votre (-ed-) module INI dans votre clib pour ne pas m'en inspirer :).

[-ed-]

Je souhaite créer une simple API qui fait l'interface entre un fichier au format INI (je devrais plutôt dire "un fichier dans *un* des formats INI vu que ça n'a pas l'air normalisé ou quoi que ce soit) et un programme.

ce n'est pas normalisé formellement, mais certains principes courants sont décrits sur le site www.wotsit.org

Lors de l'initialisation, le fichier .ini donné est ouvert et ce module crée et rempli une structure de données, image du contenu du fichier. Les commentaires ne sont pas recopiés car inutiles au programme. Ensuite le fichier est fermé et le programme travaille sur la structure de données.

Oui, si le programmeur connait à l'avance quelle est la structure utilisée... Un fichier ini n'est pas une définition de structure, mais simplement une liste de valeurs nommées, vaguement hiérarchisées...

Le "problème" :
Arrive ensuite le moment où les modifications doivent être reportées dans le fichier. Le problème est que je ne peux pas simplement ouvrir le fichier en mode w et y formater le contenu de ma structure de données,

Bien sûr, d'autant plus que le format d'un ini est texte... En fait, à partir des données internes, il faut recréer entièrement un nouveau fichier .ini. a toi d'avoir conservé les informations nécessaires (les nom des champs, par exemple !). On peut aussi agir ligne par ligne pour recopié en insérant/supprimant/modifiant ce qui doit l'être (2 fichiers que l'pon renomme/efface ensuite).

Un fichier ini, c'est bien pour quelques valeurs (10, 20 ...). Ce que fait MS avec la base de registre (énorme fichier ini de plusieurs milliers de valeurs) me parait monstrueusement complexe... Une vrai base de donnée SQL est probablement plus efficace... Il en existe de très simples, comme TinySQL.

car comme les commentaires potentiellement présents n'apparaissent pas dans cette structure, ils seraient perdus.

Je ne pense pas qu'il y ait de commentaires dans un fichier ini... Tu parles du nom des champs et de sections ?

La seule idée qui m'est venue est la suivante :

• Ouvrir le fichier .ini original en lecture.
  
• Créer un fichier temporaire ( tmpfile() ) et le remplir en croisant les informations de la structure de données (sections, variables et leur valeur) avec le contenu du fichier .ini original (commentaires).
  
• Ouvrir le fichier original en mode w et y recopier le contenu du fichier temporaire.
  

Comme ça me paraît assez lourd je me demande si je ne suis pas passé à côté d'une méthode plus simple pour modifier le contenu d'un fichier à un endroit quelconque et avec des données d'une longueur quelconque (et tout cela de manière portable) ?

C'est la seule méthode portable et sûre que je connaisse, avec l'édition manuelle à l'aide d'un éditeur de texte !

[Romu']

ce n'est pas normalisé formellement, mais certains principes courants sont décrits sur le site www.wotsit.org

Je n'ai pas trouvé de description (en tout cas celle à laquelle je m'attendais) sur le site. Pour le format j'ai juste fait un tour sur wikipédia : http://fr.wikipedia.org/wiki/Fichier_INI.

Oui, si le programmeur connait à l'avance quelle est la structure utilisée... Un fichier ini n'est pas une définition de structure, mais simplement une liste de valeurs nommées, vaguement hiérarchisées...

Je pensais faire une liste chaînée composée de structures du type

Code:


struct noeud {
    char* nom;
    char* valeur;

    struct noeud* suivant;
}

Le programmeur accède aux valeurs contenues via des fonctions mais la liste ne lui est pas visible.

Je ne pense pas qu'il y ait de commentaires dans un fichier ini... Tu parles du nom des champs et de sections ?

D'après le lien vers Wikipédia plus haut ce qui suit un ";" (ou parfois un autre caractère...) est un commentaire. J'avais fait le choix de les accepter mais finalement je vais encore y réfléchir. Si des modifications sont censées être faites à la main, avoir un document séparé indiquant la signification des champs me paraît être une bonne alternative à l'écriture de commentaires dans le fichier et la future API s'en trouverait allégée. D'un autre côté ne pas accepter de commentaires porterait un coup à la généralité de cette même API... C'est un vrai dilemme, je ne pensais pas que la difficulté allait se trouver là !

Merci en tout cas pour les informations.

[-ed-]

Rien ne t'empêche de sauvegarder le commentaire.

Attention aux liste chainées, l'accès est séquentiel. Un tableau trié permet un accès rapide (bsearch() ).

[Romu']

Rien ne t'empêche de sauvegarder le commentaire.

Comme ils sont inutiles au programme ça me gêne de les sauvegarder.

Attention aux liste chainées, l'accès est séquentiel. Un tableau trié permet un accès rapide (bsearch() ).

C'est vrai, je n'y avais pas pensé car les fichiers sont censés être petits.
Je choisis souvent des listes chaînées pour ce genre de chose car on ne connait pas le nombre de données à l'avance.
Créer un tableau impliquerait dans certains cas des realloc() et les recopies qui vont sûrement avec.
Je peux aussi choisir de créer un tableau avec le juste nombre de cases en faisant un premier passage dans le fichier pour compter le nombre de variables ? Qu'est-ce que vous en pensez ? Ca me paraît être un bon compromis... à moins que l'usage de realloc() ne soit pas si dramatique :).

C'est sûr que vu la simplicité du projet, à mon avis, même en faisant les plus mauvais choix (au niveau rapidité) tout aura l'air de s'exécuter "sans délai". Mais bon ce n'est pas une raison pour les faire.

[-ed-]

Rien ne t'empêche de sauvegarder le commentaire.

Comme ils sont inutiles au programme ça me gêne de les sauvegarder.

Qu'est-ce qui gène le plus ? De les sauvegarder ou de les perdre ? Le forma ini, c'est très moyen comme système ... C'est simple, mais évidemment, pas efficace ...

Attention aux liste chainées, l'accès est séquentiel. Un tableau trié permet un accès rapide (bsearch() ).

C'est vrai, je n'y avais pas pensé car les fichiers sont censés être petits.
Je choisis souvent des listes chaînées pour ce genre de chose car on ne connait pas le nombre de données à l'avance.

Effectivement, le problème grandit avec la taille, d'un autre coté, un petit tableau, c'est pas bien compliqué à gérer non plus ...

Créer un tableau impliquerait dans certains cas des realloc() et les recopies qui vont sûrement avec.

Oui, c'est pas tellement pire qu'un malloc() à chaque nouvel élément... Tu suis une progression genre 1 2 4 8 et ça se stabilise rapidement (doubel la taille à chaque fois). En démarrant avec une valeur raisonnable (nombre d'éléments de l'ini dans ton application, disons, 16, 32) etc., ça fait très peu de realloc...
...

Je peux aussi choisir de créer un tableau avec le juste nombre de cases en faisant un premier passage dans le fichier pour compter le nombre de variables ? Qu'est-ce que vous en pensez ? Ca me paraît être un bon compromis... à moins que l'usage de realloc() ne soit pas si dramatique :).

Oui, ça se fait aussi si on eut une taille optimisée...

C'est sûr que vu la simplicité du projet, à mon avis, même en faisant les plus mauvais choix (au niveau rapidité) tout aura l'air de s'exécuter "sans délai". Mais bon ce n'est pas une raison pour les faire.

A partir d'un centaine de valeurs, on sentira peut être une différence... Ca dépend de l'OS, de la machine...

Le principe qui doit guider le développeur est "aller au plus simple" ("Make it simple"). Si les performances sont décevantes, envisager alors d'optimiser.

Je rappelle cette fameuse citation de Donald Knuth :

"Premature optimization is the root of all evil".

http://en.wikipedia.org/wiki/Optimization_%28computer_science%29

[Romu']

Qu'est-ce qui gène le plus ? De les sauvegarder ou de les perdre ? Le format ini, c'est très moyen comme système ... C'est simple, mais évidemment, pas efficace ...

En fait je pensais par là ne pas les sauvegarder dans la structure de données interne mais des les conserver avec la méthode utilisant un fichier temporaire (décrite dans mon premier post).
Néanmoins avec le tri du tableau des variables, ça pose le problème de l'ordre dans lequel les données vont être réécrites. Pour garder l'ordre original je pense introduire aussi un numéro d'apparition en plus du nom de la variable et de sa valeur, pour pouvoir au moment de la mise à jour trier le tableau selon cet ordre d'apparition puis écrire les données.

En ce qui concerne les remarques sur l'optimisation, elles m'ont ouvert les yeux ;).

[Contenu sponsorisé]