Discussion :

[will11]

Je fais actuellement un pti programme et il y a des options que l'utilisateur sait modifier. Il faut donc que je sauvegarde ses données dans un fichier (binaire dans mon cas) pour qu'à l'exécution suivante il ne doive pas reparamètrer le programme.

Seulement j'hésite entre deux solutions au niveau de la gestion de ces paramètres:

- soit je lis et j'écris directement dans le fichier chaque fois que je dois manipuler l'un de ces paramètres (ce qui fait des accès multiple au disque dur).

- soit au lancement du programme je lis tout les paramètres du fichier et les stoque dans des variables. Quand j'ai besoin de manipuler un paramètre je lis ou j'écris dans la variable concernée. Quand l'utilisateur quitte le programme je copie les valeurs des variables dans le fichier (ainsi je n'ai que deux accès au disque dur).
Pour évité des pertes de donnée en cas d'arrêt soudain de l'ordinateur ou de l'os ou de ... je peux donner la possibilité à l'utilisateur de sauver les paramètres directement dans le fichier quand il le veut.

La première solution me paraît beaucoup plus pratique mais fait beaucoup d'accès au disque dur comparé à la deuxième solution.
Selon vous quel serait le mieux en sachant que c'est un fichier binaire et pas texte ?

ps: le programme est en C

[2Eurocents]

L'accès, en écriture, à un fichier est toujours une opération à risque...

Il suffit que la machine soit éteinte durant l'opération, et tout est fichu, surtout dans le cas d'accès arbitraires (Random Access) à un fichier binaire.

J'aurais donc assez naturellement tendance à limiter au maximum ces séquences critiques et donc à n'écrire la configuration que lors de la sortie légitime du programme, ou bien quand l'utilisateur le demande.

Il est vrai, dans ce cas, qu'une modification non sauvegardée des paramètres, invalidée par un plantage, ne sera jamais prise en compte.


Il est alors possible, pour pallier à ce défaut, de mettre en place un mécanisme à deux niveaux, avec un fichier de paramètres temporaires et un fichier de configuration.

Ainsi, au démarrage du programme, on charge le fichier de configuration et, s'il existe, le fichier de paramètres temporaires (en cas d'erreur de celui-ci, le fichier de configuration "normal" nous assure de la stabilité des paramètres). Il est "pratique", à ce niveau, de prévenir l'utilisateur de toute différence entre la configuration légitime et la configuration temporaire.

Toute modification de paramètres est enregistée immédiatement dans le fichier de paramètres temporaires.

En cas de demande de sauvegarde par l'utilisateur, ou de sortie légitime du programme, la configuration est écrite dans le fichier de configuration, et le fichier de paramètres temporaires est détruit pour ne pas géner le prochain démarrage de l'application.

Ainsi, en cas de plantage de l'appli avant la sortie légitime, la configuration non sauvegardée par l'utilisateur peut quand même être prise en compte. Voire même, au redémarrage, on peut l'avertir des différences et lui demander de les valider.

Ce n'est qu'une possibilité parmi d'autres...

[will11]

Merci, c'est vrai que c'est n'est pas mal comme solution, ça me paraît être un bon mix.
Si quelqu'un à d'autres remarques ou solutions, ça m'intéresse

[j.p.mignot]

Je suis aussi parfaitement en faveur d'une limitation au niveau des accès. En dehors des risques, il y a aussi un problème de vitesse si on doit utiliser certaines données dans des process Real-Time.
Les seuls cas où j'utilise une lecture au moment où une valeur est necessaire sont ceux où les settings, tableaux de data, ... sont trop gros pour être stockés en permanence en mémoire compte tenu d'une utilisation sporadique. (par exemple lire un fichier de help specifique à une situation, charger des conditions de print, ...)

[chebreg]

ma proposition pourrait paraitre out,
mais pour quoi ne pas implémenter le système de paramétrage avec base de données. avec des tables bien indexées, et un grand nombre de paramètres à gérer. il me semble que cette méthode sera plus efficace.
en plus il sera possible d'implémenter un mécanisme de chargement "Ondemande" des paramètres s'il ont une structure hiérarchique.

sur les trucs de parametre, ya un tutoriel sur la question avec un framework en Java [le Jakarta Commons Configuration]. c'est intéressant à regarder :http://beuss.developpez.com/tutoriel...configuration/)
Ça pourrait etre une source d’inspiration.