Les premières questions que vous devez vous poser sont le qui et le pourquoi. Vos options sur le suivront.
Alors, qui (ou quoi) va accéder aux données? Si c'est juste le programme lui-même alors vous pouvez stocker les données que vous voulez - fichier binaire, xml, base de données, fichier ini, peu importe. Cependant, si les données doivent être facilement accessibles à l'utilisateur pour qu'elles puissent les modifier avant une exécution, un fichier texte comme un ini, qui peut être facilement modifié, a du sens. Afin de modifier les données stockées dans d'autres formats, vous devrez peut-être écrire un programme entièrement séparé juste pour manipuler les paramètres stockés. Peut-être que cela a du sens dans votre situation ou peut-être pas, mais ce sera plus de travail.
Si vous choisissez d'emprunter la route ini, vous êtes sur la bonne voie. Ce ne sont que des fichiers texte. Un format commun est d'avoir des sections (généralement entre parenthèses), puis des paires clé/valeur dans les sections. Habituellement, les lignes de commentaires commencent par un point-virgule, ce qui est une bonne idée pour les utilisateurs qui voudront passer d'un paramètre à l'autre.
donc quelque chose comme ceci:
[System]
datapath = /home/me/data
[Application]
start_count = 12
; start_count = 20 //this is a comment
Vous n'avez pas à vous soucier des lignes spécifiques pour vos données. Vous venez de lire le fichier ligne par ligne. Les lignes vides ou commentées sont jetées. Vous prenez note de la section dans laquelle vous vous trouvez et vous traitez les paires clé/valeur.
Il existe plusieurs façons de stocker le fichier analysé dans votre programme. Un simple peut être de concaténer le nom de la section et la clé dans une clé pour une carte. La valeur (de la paire clé/valeur) serait les données pour la carte. Donc, "Systemdatapath" pourrait être une clé de carte et sa valeur serait "/ home/me/data". Lorsque votre programme a besoin d'utiliser les valeurs, il le regarde par clé.
C'est l'essentiel. En fin de compte, vous voudrez l'embellir. Par exemple, des méthodes pour récupérer des valeurs par type. Par exemple. getString(), getInteger(), getFloat(), etc.
Super, exactement ce que j'avais besoin de savoir. Je pense que je vais le garder avec .ini, si ce n'est que pour la simplicité. Je voulais juste m'assurer que tant que je l'analyserais à ma façon et que j'y accéderais à ma façon, cela n'aurait pas d'importance s'il y avait une convention en place (ou peu importe). +1 et réponse sélectionnée – jkeys