Discussion :

[BioKore]

Bonjour à tous,

Dans les différents "programmes" que je créé, il s'avère que, dans certains cas, il me serais bien intéressant de réaliser des fichiers de configuration de paramètres plutôt que de devoir tout recompiler à chaque fois, ou pire, demander une configuration interactive.
Je me demandais donc si, par hasard, il existait une sorte de norme ou des principes spécifiques à appliquer lorsque l'on souhaite réaliser des fichiers de configuration pour un programme particulier.

Pour le moment mes besoins sont simples, mais à l'avenir il est possible que je doive utiliser plusieurs fichiers de configuration, mais avec assez peu de paramètres dans tous les cas. Je pense faire le parseur moi-même pour démarrer, j'aviserais de prendre une bibliothèque plus complexe si nécessaire par la suite.

Merci d'avance.

[Bousk]

Non il n'y a pas de règles ou normes.
Tu fais ce que tu veux.
Un .ini, un json, un xml, ... tu définies ton format et le parse.
Ou utilise une lib de parsing et adaptes ton fichier au format qu'elle attend.

[BioKore]

Ok ! Je ferais à ma sauce alors.

Merci pour le retour !

[foetus]

un peu de pub pour la librairie Jansson : elle est écrite en C et est toute petite, la prise en main est rapide, la documentation est bien faite
Après cela reste du json : l’Unicode est pris en charge mais ne fait pas parti de la norme (tout en ASCII), pas de commentaire (à part soit créer des clefs bidons soit doubler les clefs - seule la dernière valeur est prise en compte ... en théorie)

[jo_link_noir]

Json est tout sauf pratique comme fichier de configuration:

- C'est pénible à écrire (des guillemets partout)
- L’interprétation du contenu des caractères va dépendre de la lib (\n -> saut de ligne ou 2 caractères ?)
- Il n'y a généralement aucun moyen de connaître les doublons ce qui n'est absolument pas pratique dans de grosse configuration où l'utilisateur peut se tromper
- Les commentaires n'existent pas, ce qui est peut-être le pire et empêche d'avoir un fichier par défaut auto-documenté.

C'est uniquement un format de transfert qui en plus n'est pas des plus efficaces.

Personnellement, j'aime bien le .ini (qui est déjà utilisé par beaucoup de logiciel sur Linux). Ce n'est pas compliqué, mais il possède 2 des problèmes du json (2 et 3 du dessus).

[BioKore]

Merci pour ces quelques conseils.

Effectivement, le fait d'avoir des commentaires semble intéressant, même lorsque les fichiers de conf sont courts / simples.
Cependant, le fait d'avoir une bibliothèque "petite et simple" est aussi un avantage.

Je vais voir comment sont faits les *.ini. Il y a probablement du bon à tirer des deux mondes (json et ini).

Merci.

[Invité]

Salut,
Regarde du côté de YAML, Ca permet de faire plein de choses facilement et c'est de plus en plus populaire. Et surtout, il y a des libs pour à peu près tous les langages.

[BioKore]

Super, je te remercie. L'écriture et la lecture de tels documents me semble simple et correspondrait tout à fait à ce que j'imaginais.
Reste à vois comment ça s'intègre concrètement ; mais ça, je m'y pencherais d'ici peu.

Merci.

[koala01]

Salut,

Une bibliothèque qui est pas mal, parce qu'elle te permet de créer des fichiers de configuration à différents format, tout comme elle te permet de définir des options d'exécutions (en ligne de commande) est la bibliothèque Boost.Program_options

Elle présente, de plus, l'énorme avantage d'être développée en C++ et non en C

Elle pourrait peut-être t'aider à faire ce que tu souhaite

[BioKore]

Merci pour la proposition ; je regarderais ça aussi. Ce sera peut être l'occasion de me télécharger boost...

[foetus]

Elle présente, de plus, l'énorme avantage d'être développée en C++ et non en C

Il faut se demander surtout quel est l'avantage d'avoir du code objet

@BioKore se demandait comment l'intégrer au code. Avec du C (valable aussi en C++), tu n'as qu'à faire 1 grosse fonction (*) qui va parser ton fichier en entrée et remplir un DTO (<- lien wiki en anglais, en gros 1 classe avec que des membres sans logique autre que des accesseurs/ modificateurs et pour sérialiser).
Simple et rapide ... juste mettre des commentaires dans la fonction (*) pour décrire les étapes parce qu'elle risque d'être assez longue (ou éventuellement faire des petites fonctions d'extraction pour telle ou telle section/ partie)

Pas la peine d'avoir des formateurs de flux, des listes d'options ou autres

Et l'autre truc , c'est vrai que le format json a des défauts ... mais il permet nativement d'avoir des objets et des tableaux.
Avec un fichier clef/valeur, il faut sûrement reparser la valeur pour extraire les donnés s'il n'y a pas qu'1 seule.

[BioKore]

Oui, comme je le disais, mes fichiers de conf s'annoncent, au moins dans un premier temps, relativement lights ; l'idée de tout regrouper dans une seule structure me semble tout à fait raisonnable et pratique.

Initialement, j'imaginais même faire le parser moi-même, qui se révélerait relativement "court". Pour en revenir à la "première partie" de la question initiale, il s'agissait vraiment du formalisme des fichiers de conf en tant que tel. Si des principes précis avaient été en place, autant les utiliser ; idem pour l'intégration.

Après, je suis d'accord ; le fait d'utiliser une lib en C est probablement un inconvénient dans certains cas, mais lorsqu'il s'agit de bibliothèques "courantes" et/ou simple à utiliser et wrapper, à performances égales, c'est aussi un avantage : je connaîtrait une lib en C si un jour je décide de me remettre à ce langage...

En tout cas, merci pour ces suggestions.

[Invité]

@BioKore Perso je trouve ta démarche tout à fait valable. A mon avis, il faut effectivement utiliser un format bien connu et privilégier une lib qui fait le job simplement et efficacement. Boost contient de très bonnes libs mais c'est une grosse dépendance et qui peut rapidement faire exploser le temps de compilation. Après pour le parsing "à la main", je pense que c'est un piège : au début tout va bien, on code l'essentiel assez facilement mais rapidement on va vouloir rendre le code un peu robuste et avec une gestion d'erreur, et là ça peut vite devenir compliqué...