Discussion :

[ChriGoLioNaDor]

Bonjour,

J'aimerais stocker des paramètres dans un fichier de config (nombre de threads à lancer, port d'écoute utilisé, maximum de personne en file d'attente, ...).

Pourriez-vous me conseiller sur le type de fichier à utiliser, pour avoir une solution robuste, simple, rapide, et portable (utilisable aussi bien sous Linux, Windows, et Mac) ?

J'ai en particulier entendu parler de fichiers ini et xml, mais je ne sais pas quelle est la meilleure solution. XML semble moins utilisée en C++ (plutot utilisée pour le web), et les fichiers ini semblent être en voie de disparition...

Bref quelle est la solution couramment utilisée pour lire/éditer les fichiers de config actuellement? Existe-t'il des fonctions standardisées permettant la lecture de ces fichiers, que ce soit sous Windows ou sous Linux?

Merci d'avance pour vos réponses!

[albat0r]

Tu peux utiliser Boost.program_options qui est mal du tout et qui permet de lire une configuration aussi bien de la ligne de commande que d'un fichier.

[ChriGoLioNaDor]

Le soucis est que j'aimerais inclure un minimum de librairies externes : je vais créer des threads, des sockets, une interface graphique, éventuellement la gestion du son plus tard... Le tout le plus portable possible. Je ne me vois pas utiliser 36 librairies différentes, dont je ne controlerais pas la qualité/l'évolution.

En continuant mes recherches, j'ai entendu parler de Boost, qui semble gérer les threads et les socket, mais le documentation me semble un peu ostère... Il peut faire plein de choses, mais c'est pas vraiment bien expliqué ^^

J'ai aussi lu du bien de SDL (en particulier SDL_NET) pour ce qui est du réseau, et ça semble encore être une librairie assez généraliste.

[Bayard]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

XML semble moins utilisée en C++ (plutot utilisée pour le web)

-> Je ne suis pas d'accord. XML est parfait comme fichier de configuration.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

les fichiers ini semblent être en voie de disparition

-> Je suis d'accord.

[ChriGoLioNaDor]

Bon ok, vous m'avez convaincu (vous et mes recherches ), je vais opter pour du XML.

Reste à trouver un parseur (il me semble que c'est comme ça qu'on appelle ça ), me permettant de lire et d'éditer ce type de fichier.

Auriez-vous des librairies à me conseiller?
Mon but :
- Robustesse : un code propre, qui n'affiche pas 36 warning/erreur si on n'utilise pas le même compilateur que celui ayant créé le module ^^
- Fonctionnalités de base : lire une entrée, la modifier, à la limite en ajouter une... C'est tout ... Pour le moment
- Rapidité : pas une usine à gaz qui sait faire plain de chose, mais qui est leeeeente
- Simplicité d'utilisation : pas 36 trucs à bidouiller pour l'installer, que ce soit sous Linux ou sous Windows (un fichier à inclure serait parfait); pas 36 paramètres à passer, variables à initialiser, ...

Bref un truc simple et propre ^^

J'ai entendu parler pour le moment de TinyXML et de libXML. Je suis entrain d'essayer d'en savoir plus à leur sujet, leurs avantages et inconvéniants, leur facilité d'installation/d'utilisation... Mais si vous avez des avis à partager, ils sont biensûr les bienvenus!

[Luc Hermitte]

Le XML c'est overkill comme solution pour des fichiers d'initialisation. (quand en plus on voit que des solutions tout XML reposent sur des .properties qui sont eux de bêtes .rc ... il y a de quoi se poser des questions).

Le .rc est ce qu'il y a de plus simple et passe partout. C'est du .ini en plus simplifié (pas de sections). boost.program_options est parfait pour cela.

N'espère pas éditer ton .xml à la main, l'XML n'est pas fait pour ça. Un .rc ou un .ini, c'est fait pour. Si tu ne voulais pas introduire de dépendances et autres trucs compliqués, tu t'es trompé de techno avec l'XML.


Si à termes tu dois utiliser une bibliothèque de fenétrage, alors choisis-en une dès maintenant, et regarde les solutions qu'elle propose pour gérer fichiers de conf, sockets, threads, ... Souvent les frameworks de fenétrage font plus que juste les fenêtres.

[Sylvain Togni]

-> Je ne suis pas d'accord. XML est parfait comme fichier de configuration.

Moi je trouve que c'est vraiment utiliser un rouleau compresseur pour écraser une mouche. C'est plus long et difficile d'installer et d'apprendre à utiliser un parseur XML que de faire la lecture du fichier de config à la main, dans un format simple, une entrée par ligne, une tabulation entre la clé et la valeur, par exemple.

[nikko34]

pour parser un fichier ini, tu peux utiliser SimpleIni et directement inclure ses 3 fichiers dans ton projet.

[PierroElMito]

C'est plus long et difficile d'installer et d'apprendre à utiliser un parseur XML que de faire la lecture du fichier de config à la main, dans un format simple, une entrée par ligne, une tabulation entre la clé et la valeur, par exemple.

C'est pas forcément beaucoup plus long: TinyXML est super simple a utiliser pour ce genre de choses et très efficace.

[Bayard]

N'espère pas éditer ton .xml à la main, l'XML n'est pas fait pour ça.

-> 1) un simple éditeur fonctionne à merveille.
-> 2) en double cliquant dessus Internet Explorer permet de voir le fichier sans le modifier. Excellent si l'on ne désire pas qu'un utilisateur modifie le fichier.


http://sourceforge.net/projects/tinyxml/

Bonne journée.

[koala01]

(snip)
-> 2) en double cliquant dessus Internet Explorer permet de voir le fichier sans le modifier. Excellent si l'on ne désire pas qu'un utilisateur modifie le fichier.

Heuu, à condition que l'utilisateur n'aie pas un logiciel pour la création de site web qui aurait redéfini l'association avec xml à son profit

Et avec l'engouement actuel pour la création de sites web, tu peux te dire que la probabilité est grande

De plus, je rejoins l'avis selon lequel un fichier xml est peut être un peu ... excessif s'il ne s'agit que de sauvegarder quelques données de configuration.

Et, comme l'a indiqué luc, les bibliothèques graphiques actuelles fournissent généralement une solution pour la grosse majorité des besoins énoncés par ChriGoLioNaDor en plus de la gestion d'options de configurations...

Du coup, je ne peux que plussoter avec son conseil de choisir dés maintenant la bibliothèque graphique, et de lui laisser faire tout le boulot pour lequel elle est prévue (gestion configuration, socket, threads, ...) ce qui rejoindra, enfin, le dernier besoin de ChriGoLioNaDor qui est d'éviter d'apporter des dépendances de tous côtés...

@ ChriGoLioNaDor==> Si tu te rallie à mes arguments (et à ceux de luc), les principales bibliothèques graphiques portables sont QT, wxWidget et gtkmm...

Il faut savoir que QT, par exemple, est soumis à licence si tu décide de ne pas fournir ton application sous les termes de la licence GNU/GPL... mais, est tout à fait gratuit si tu décide de le fournir sous cette licence.

wXwidget est, pour sa part, un pur produit Open Source, sauf erreur

Je ne suis malheureusement pas certain que gtkmm soit portable (je ne l'ai jamais utilisé), mais c'est aussi un produit soumis à la licence GNU/GPL

Tu devrais trouver, dans le forum et dans la FAQ, à peu près toutes les informations que tu pourrais souhaiter

[Luc Hermitte]

-> 1) un simple éditeur fonctionne à merveille.
-> 2) en double cliquant dessus Internet Explorer permet de voir le fichier sans le modifier. Excellent si l'on ne désire pas qu'un utilisateur modifie le fichier.

1) Ce n'est pas ce que j'appelle maintenable. Sans parler de la facilité avec laquelle cela se corromp

2) Là, je ne vois plus l'intérêt d'appeller ça un fichier de conf.

[ChriGoLioNaDor]

En fait je pensais utiliser WxWidgets, qui gère justement tout ce qui est thread et socket. Par contre je n'ai pas vu qu'il gérait les fichiers de configuration.

Après lecture, il est vrai que ça semble un peu complexe d'utiliser XML pour gérer les options : je n'en aurais pas ennormément, je n'utiliserais pas de section, et pour modifier le fichier à la main rapidement... :S

Par contre, je pense l'utiliser pour la gestion des fenêtes : un fichier XML pourrait me servir à décrire les éléments d'une fenêtre (position, taille, options, position des boutons, ...). Le but étant d'avoir une possibilité de modifier/créer une interface utilisateur facilement. Mais là on sort du cadre du sujet initial...

[BainE]

Bonjour,

personnellement, pour un fichier de configuration, le .ini, y a pas plus rapide, a moins de stocker de tableau de structure où là, a la limite ca peux etre interessant.

Encore une fois, *personnellement*, cette mode de mettre du XML de partout devient limite masochiste.

[Sylvain Togni]

En fait je pensais utiliser WxWidgets, qui gère justement tout ce qui est thread et socket. Par contre je n'ai pas vu qu'il gérait les fichiers de configuration.

Si, la classe s'appelle wxConfig.

Par contre, je pense l'utiliser pour la gestion des fenêtes : un fichier XML pourrait me servir à décrire les éléments d'une fenêtre (position, taille, options, position des boutons, ...). Le but étant d'avoir une possibilité de modifier/créer une interface utilisateur facilement.

C'est exactement ce que propose le système de ressource de wxWidgets qui se nome XRC

[Bayard]

OK, je propose

Fichier simple: -> .INI
Fichier complexe (par exemple avec structure en arbre): -> .XML

[koala01]

C'est à peu près cela...

[Luc Hermitte]

J'irai même jusqu'à dire :
- fichier humainement modifiable : .ini/.totorc
- fichier géré (lecture ET écriture) par l'outil : xml

Pour les arborescences, un peu d'imagination dans les noms des paramètres suffit amplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
# un commentaire
arbre1.noeud1.toto = valeur
 
arbre2.noeud42.sous-noeud.toto = 42

[ChriGoLioNaDor]

Merci beaucoup pour toutes ces précisions, vous m'avez fait gagné un temps précieux!

Je classe le sujet en [Résolu]

[Médinoc]

Attention:
Reste à savoir OÙ placer le fichier de configuration : Si c'est dans le même dossier que le programme, ça signifie que seuls les adiministrateurs peuvent modifier la config...

Sous Linux, il faut donc placer le fichier dans $HOME, sous Windows, généralement dans le dossier Application Data de l'utilisateur (%APPDATA% ou SHGetSpecialFolderPath()) ou, de préférence, en base de registre (HKEY_CURRENT_USER\Software\NomDeLEntreprise\NomDeLApplication)...