Discussion :

[Steph_ng8]

Bonjour,
La question n'est pas « Comment analyser les paramètres », mais plutôt « De quelle manière le faire ».

Comment ça c'est pareil ???
Bon, je vais préciser...
« De quelle manière analyser les paramètres passés à un programme pour respecter une approche C++ correcte ? »

Voilà ce que je fais d'habitude :

Code Analyse de paramètres :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
struct parametres
{
 
    /**
     * @brief Analyse les paramètres d'un programme.
     * @param argc nombre de paramètres du programme (y compris argv[0]).
     * @param argv liste des paramètres du programme (y compris argv[0]).
     * @return @c true si la lecture des arguments permet l'exécution du programme,
     *         @c false sinon.
     * 
     * @note Si l'un des paramètres demande l'affichage de l'aide, le programme
     *       s'arrêtera immédiatement après avec le code de sortie EXIT_SUCCESS.
     */
    bool operator () (int argc, char **argv);
 
  private:
    /**
     * @brief Affiche un message d'aide et quitte.
     * @param prog nom du programme (argv[0]).
     * 
     * @note Cette fonction appelle std::exit(EXIT_SUCCESS).
     */
    void aide(char const *prog);
 
}; // struct parametres

En fonction du programme, la classe contient également des variables membres pour représentsr les paramètres, et les accesseurs (constants) qui vont avec.

Pour ceux qui se demandent pourquoi je retourne un booléen, disons que j'ai été traumatisé par des appels à exit qui ne permettaient pas de libérer toutes les ressources (même statiques, si ma mémoire est bonne...).
Je n'ai malheureusement pas d'exemple, et je ne me souviens même plus si c'était en C ou en C++.

Bref, du coup je préfère sortir du programme directement dans le main à l'aide de l'instruction return, quand c'est possible.
Évidemment, on pourrait très bien retourner le code de sortie (différent de EXIT_SUCCESS) à la place d'un booléen.

Voilà...
Toutes les remarques sont les bienvenues !

[jblecanard]

Salut !

Perso, j'utilise boost::program_options. Ca fait le travail rapidement et bien. Ca présente l'inconvénient de n'être pas header only, mais moi ça ne me pose aucun problème.

[Steph_ng8]

Hum... je l'avais oublié, celui-là...

Je connaissais, mais dans le cas présent je me limite au cas où l'utilisateur ne peut ou ne veut pas installer boost (ou une autre bibliothèque).

[jblecanard]

L'utilisateur, ou le développeur ? Si tu link en statique, l'utilisateur n'aura rien à installer de plus que ton programme.

[koala01]

Salut,

Hum... je l'avais oublié, celui-là...

Je connaissais, mais dans le cas présent je me limite au cas où l'utilisateur ne peut ou ne veut pas installer boost (ou une autre bibliothèque).

Si tu crées un exécutable et non une bibliothèque, et que, au pire, tu linke en dynamique, qu'est ce qui t'empêche de rajouter la dll de boost éventuellement nécessaire à ton installateur

[Steph_ng8]

L'utilisateur, ou le développeur ?

L'utilisateur.
Ou pour être plus précis, celui qui doit recompiler les sources sur sa machine.

Si tu link en statique, l'utilisateur n'aura rien à installer de plus que ton programme.

Si tu crées un exécutable et non une bibliothèque, et que, au pire, tu linke en dynamique, qu'est ce qui t'empêche de rajouter la dll de boost éventuellement nécessaire à ton installateur

Je crée bien un exécutable, et mon installateur se résume à un Makefile.
Quant à rajouter une DLL, je l'ai fait une fois (pour Qt), et elle était (beaucoup) plus lourde que programme.
Je ne sais pas combien de modules doivent être chargés pour pouvoir utiliser boost::program_options, mais je me demande si cela vaut le coup d'ajouter une DLL lourde juste pour disposer d'un analyseur de paramètres.

De plus, c'est vrai que je ne l'ai pas précisé, mais je travaille essentiellement sous Linux (même si j'aimerais que ce soit portable sur Windows et MAC OS).
Alors pour les DLL on repassera...
Quoique j'imagine que dans ce cas il y a des .so...

Ceci dit, ce n'est pas vraiment le problème.
Encore une fois, la question n'est pas « comment faire », mais « de quelle manière le faire pour que ce soit conceptuellement correct et cohérent », si possible en réduisant les dépendances extérieures aux minimum.
Ce n'est pas une question de méthode, mais de design.

Je sais pertinemment que boost est un outil puissant et qu'il le fera toujours mieux que moi.
Mais dans l'immédiat, je n'ai pas besoin d'autant de puissance.

Je comprendrais parfaitement que vous me trouviez borné, voire étroit d'esprit.
Alors dites-vous que mon plus gros problème en C++ à l'heure actuelle se situe au niveau de la conception, et que le problème présent n'est qu'un exemple sur un cas précis.

[jblecanard]

Ben si le débat est sur le design d'un tel outil, pourquoi pas. Pour bien designer, il faut commencer par étudier le use case.

Pour moi, le use case, c'est :
- Déclaration des options possibles à l'outil.
- Passage de argc et argv à l'outil pour interprétation
- Lecture du résultat

Je vois bien un système avec un map<string,string> pour stocker le résultat. On peut faire un proto assez simple.