IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Analyser les paramètres passés à un programme


Sujet :

C++

  1. #1
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut Analyser les paramètres passés à un programme
    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 !

  2. #2
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    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.
    Find me on github

  3. #3
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut
    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).

  4. #4
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    L'utilisateur, ou le développeur ? Si tu link en statique, l'utilisateur n'aura rien à installer de plus que ton programme.
    Find me on github

  5. #5
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 614
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 614
    Points : 30 626
    Points
    30 626
    Par défaut
    Salut,
    Citation Envoyé par Steph_ng8 Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #6
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut
    Citation Envoyé par jblecanard Voir le message
    L'utilisateur, ou le développeur ?
    L'utilisateur.
    Ou pour être plus précis, celui qui doit recompiler les sources sur sa machine.

    Citation Envoyé par jblecanard Voir le message
    Si tu link en statique, l'utilisateur n'aura rien à installer de plus que ton programme.
    Citation Envoyé par koala01 Voir le message
    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.

  7. #7
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    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.
    Find me on github

  8. #8
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut
    Oulà...
    Moi j'étais simplement parti sur une structure de base à adapter en fonction des besoins.

    On passe argc et argv à l'operator(), qui se charge de faire tout le boulot (analyser les formes courtes/longues des options, les options avec/sans argument, les formes "-options=valeur"/"-option valeur", etc.).
    Une fonction membre privée aide() (ou help()) sert à afficher le message d'aide, puis quitte.
    Quand on veut la valeur d'un paramètre, on utilise l'accesseur approprié.

    C'est comme ça que je voyais les choses.
    Certes, il faut le réécrire pour chaque programme, et si on ajoute une option il faut modifier pas mal de choses...

    Mais on peut discuter sur une solution générique.
    jblecanard, quand tu parles d'« outil », tu parles de refaire un boost::program_options-like ?
    Ce qui me gêne, c'est toute la configuration et le stockage de données (nom option/description) qu'il faut faire pour quelque chose qu'il n'est utilisé qu'une fois au début du programme.
    Et puis une fois l'analyse effectuée, on recherche les valeur par comparaison de chaînes sur les clés...
    Certes, elles ne sont probablement pas très longue, et il n'y en aura pas des masses à faire.
    M'enfin, en termes d'exécution, c'est quand même plus rapide et moins lourd de parser des chaînes une seule fois et de stocker les valeurs dans des variables accessibles directement, non ?
    Je ne vois pas tellement d'avantage à cette méthode à part une simplicité d'écriture pour le programmeur (et de relecture, peut-être...).

    Une dernière chose, comment tu fais pour stocker des données numériques dans un map<string, string> ?
    Oh, je vous vois venir...
    map<string, boost::variant>, non ?

  9. #9
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Citation Envoyé par Steph_ng8 Voir le message
    jblecanard, quand tu parles d'« outil », tu parles de refaire un boost::program_options-like ?
    Oui et non. Oui, mais plus simple.

    Citation Envoyé par Steph_ng8 Voir le message
    Ce qui me gêne, c'est toute la configuration et le stockage de données (nom option/description) qu'il faut faire pour quelque chose qu'il n'est utilisé qu'une fois au début du programme.
    Et puis une fois l'analyse effectuée, on recherche les valeur par comparaison de chaînes sur les clés...
    Certes, elles ne sont probablement pas très longue, et il n'y en aura pas des masses à faire.
    M'enfin, en termes d'exécution, c'est quand même plus rapide et moins lourd de parser des chaînes une seule fois et de stocker les valeurs dans des variables accessibles directement, non ?
    Ne confondons pas les responsabilités ! L'objet qui parse les options n'a pas à décider de ce qui se passe ensuite dans le programme. Si le stockage te gêne, il suffit de détruire l'objet une fois les infos récupérées. Tu ne devrais pas utiliser le même objet pour parser les options et pour stocker le résultat dans tout le programme. Pour moi, ce sont deux responsabilités différentes.

    Voici un proto simpliste :

    Code : 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
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    #include <string>
    #include <vector>
    #include <map>
    #include <exception>
    #include <utility>
    #include <algorithm>
    #include <iostream>
     
    class ArgumentParser
    {
      struct Option {
        std::string name;
        std::string shortcut;
        std::string defaultValue;
        bool valueMandatory;
      };
     
      std::map< std::string, std::string > m_options;
      std::vector< Option > m_possible;  
     
      void AddOption(std::string const & iName, std::string const & iDefaultValue, bool iValueMandatory)
      {
        Option option;
        option.name = iName;
        option.shortcut = iName.substr(0,1);
        option.defaultValue = iDefaultValue;
        option.valueMandatory = iValueMandatory;
     
        m_possible.push_back(option);
      }
     
    public:
      ArgumentParser()
      {}
     
      virtual ~ArgumentParser()
      {}
     
      void AddOption(std::string const & iName)
      {
        AddOption(iName,std::string(""),false);
      }
     
      void AddOption(std::string const & iName, char * const iDefaultValue)
      {
        AddOption(iName,std::string(iDefaultValue),false);
      }
     
      void AddOption(std::string const & iName, std::string const & iDefaultValue)
      {
        AddOption(iName,iDefaultValue,false);
      }
     
      void AddOption(std::string const & iName, bool iValueMandatory)
      {
        AddOption(iName,std::string(""),iValueMandatory);
      }
     
      void ParseCommandeLine(int iArgc, char * iArgv[])
      {
        std::vector< std::string > cmdContent;
        for(int i = 0; i < iArgc; i++)
          cmdContent.push_back(std::string(iArgv[i]));
     
     
        for(std::vector< Option >::iterator it = m_possible.begin(); it != m_possible.end(); it++)
        {
          std::vector< std::string >::iterator foundOption;
          std::string pattern = std::string("--") + it -> name;
          foundOption = std::find(cmdContent.begin(), cmdContent.end(), pattern);
          if(foundOption == cmdContent.end() )
          {
            pattern = std::string("-") + it -> shortcut;
            foundOption = std::find(cmdContent.begin(), cmdContent.end(), pattern);
          }
     
          if(foundOption != cmdContent.end() )
          {
            std::vector< std::string >::iterator nextText = foundOption + 1;
            bool hasNext = (nextText != cmdContent.end());
            bool nextIsOption = hasNext ? (nextText -> substr(0,1) == "-") : true;
     
            if(it -> valueMandatory && nextIsOption)
            {
              throw std::exception("Valeur obligatoire pour une option n'a pas été spécifiée");
            }
            else
            {
              if(nextIsOption)
                m_options.insert(std::make_pair(it -> name, it -> defaultValue));
              else
                m_options.insert(std::make_pair(it -> name, *nextText));
            }
          }
        }
      }
     
      bool HasValue(std::string const & iName)
      {
        return (0 < m_options.count(iName));
      }
     
      bool GetValue(std::string const & iName, std::string& iValue)
      {
        bool result = HasValue(iName);
        if(result)
          iValue = m_options[iName];
     
        return result;
      }
    };
     
    int main(int argc, char* argv[])
    { 
      ArgumentParser options;
      options.AddOption("help");
      options.AddOption("roger","ouai");
      options.AddOption("marcel",true);
     
      options.ParseCommandeLine(argc,argv);
     
      if(options.HasValue("help"))
      {
        std::cout << "Affichage de l'aide !" << std::endl;
      }
      else
      {
        std::string RogerValue;
        if(options.GetValue("roger",RogerValue))
          std::cout << "Roger vaut : " << RogerValue << std::endl; 
     
        std::string MarcelValue;
        if(options.GetValue("marcel",MarcelValue))
          std::cout << "Marcel vaut : " << MarcelValue << std::endl; 
      }
      return 0;
    }
    Quelques commandes possibles avec l'exemple fourni :

    Code : 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
    >TstDeBase.exe -h
    Affichage de l'aide !
     
    >TstDeBase.exe --help Allo ?
    Affichage de l'aide !
     
    >TstDeBase.exe --roger
    Roger vaut : ouai
     
    >TstDeBase.exe -r oui -m non
    Roger vaut : oui
    Marcel vaut : non
     
    >TstDeBase.exe --marcel salut
    Marcel vaut : salut
     
    >TstDeBase.exe -m
    << Plantage du programme (exception non gérée) >>
    Après pour la lecture d'arguments numériques, tu te débrouilles ailleurs avec les stringstream. Voir la FAQ à ce sujet. Tu peux l'intégrer à l'outil, ou pas.

    Après on peut avoir un débat sur la bonne manière de gérer la session et la manière de stocker et d'utiliser les options dans le programme (une fois parsées). C'est pour moi un sujet différent.
    Find me on github

  10. #10
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2010
    Messages
    434
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2010
    Messages : 434
    Points : 654
    Points
    654
    Par défaut
    Bonjour,

    L'avantage du map c'est ça table de hash donc si tu as plusieurs paramètre a vérifié et qu'ils sont optionnel c'est mieux de le faire comme ça.

    Tu optimise pas ton code si tu compare ta chaîne avec tout les cas possible et cela pour tout les paramètres disponible, surtout qu'a la base tu aura toujours une chaîne de caractères vu que argv est un char**.

    Dans un .h tu peux faire des defines pour faciliter le changement des valeurs en fonctions du projets.

    Après tu peux faire dans un .c en extern un tableau de tableau écrit en dur avec des defines.

    Puis dans ton map tu peux string, ptr_fct|ptr_method.
    Comme ça tu garde ton compteur dans ta classe et tu peux avancé dans tes methode si tu attend un truc de précis.

    Après dans stocker tes entrées bah la tu est obliger de spécialisé en fonction du programme API ou autres a toi de voir

    Si c'est des options style -v(verbose).. bah la le mieux c'est un masque binaire pour stocker tes valeurs. Mais si c'est toto = 1 la tu est obliger de faire un int toto = 1 d'ou le ptr sur fonction qui peut t'aider a spécialiser ta classe.

    Ensuite pour la partie des erreurs un système d'exception c'est pas mal aussi histoire que le gars ce tapes pas un man mais plutôt l'erreur ciblé.
    La aussi a coup de defines ça va vite.

    Et pour certains paramètres es-qu'une gestion de fichier de conf ne vaut il pas le coup.

    Bonne journée en espérant avoir était clair.

  11. #11
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Citation Envoyé par jouana Voir le message
    Dans un .h tu peux faire des defines pour faciliter le changement des valeurs en fonctions du projets.

    Après tu peux faire dans un .c en extern un tableau de tableau écrit en dur avec des defines.
    Alors là, je dis non. C'est une très mauvaise manière de s'y prendre.

    Citation Envoyé par jouana Voir le message
    Et pour certains paramètres es-qu'une gestion de fichier de conf ne vaut il pas le coup.
    Si le jeu d'options est complexe, oui c'est une bonne idée !
    Find me on github

  12. #12
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut
    Citation Envoyé par jouana Voir le message
    L'avantage du map c'est ça table de hash
    Euh... on parle bien de std::map ?
    Depuis quand ça se base sur une table de hachage ?
    Il me semblait plutôt que ça se basait sur un ordre strict.
    La table de hachage, c'est std::unordered_map, non ?
    À condition d'avoir un compilateur qui supporte le C++0x...
    (Je vous rassure, c'est mon cas.)
    [Edit]Et en plus, je ne suis pas à l'aise pour écrire des fonctions de hachage...[/Edit]

    Citation Envoyé par jblecanard Voir le message
    Citation Envoyé par jouana Voir le message
    Dans un .h tu peux faire des defines pour faciliter le changement des valeurs en fonctions du projets.

    Après tu peux faire dans un .c en extern un tableau de tableau écrit en dur avec des defines.
    Si le jeu d'options est complexe, oui c'est une bonne idée !
    Je suis d'accord, et je précise que si je m'amuse à faire l'analyse « à la main », c'est que c'est relativement simple ! (du moins, jusqu'à présent)

    Citation Envoyé par jblecanard Voir le message
    Ne confondons pas les responsabilités ! L'objet qui parse les options n'a pas à décider de ce qui se passe ensuite dans le programme.
    Quand je vous disais que mon principal problème en C++ était au niveau de la conception...

    Citation Envoyé par jblecanard Voir le message
    Après pour la lecture d'arguments numériques, tu te débrouilles ailleurs avec les stringstream.
    Oui, ça je sais faire.
    C'est juste que je trouvais idiot de les stocker sous forme de chaîne de caractères, et de les reparser à chaque fois qu'on en a besoin.

    @jblecanard, je vais étudier ta proposition en détails.
    Je vous tiens au courant.

  13. #13
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Citation Envoyé par Steph_ng8 Voir le message
    C'est juste que je trouvais idiot de les stocker sous forme de chaîne de caractères, et de les reparser à chaque fois qu'on en a besoin.
    Ce n'est pas optimal oui. Après dans la majorité des cas, les options peuvent se traiter par code dans le main ou une classe dédiée. Si tu as besoin de créer des objets dont la configuration dépend de ces options, une bonne idée est de :

    - Mettre ces options dans une structure
    - Passer cette structure à une factory qui créera les objets en fonction des valeurs
    Find me on github

  14. #14
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut
    [Ligne 61]
    Code [Ligne 61] : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    std::vector< std::string > cmdContent;
    for(int i = 0; i < iArgc; i++)
      cmdContent.push_back(std::string(iArgv[i]));
    Ce ne serait pas plus simple de faire :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    std::vector< std::string > cmdContent(iArgv, iArgv + iArgc);
    Quoique vu comment tu as déclaré iArgv, le compilateur risque de décréter que les deux Input Iterators n'ont pas le même type.
    Tiens, justement...

  15. #15
    Membre éprouvé Avatar de Steph_ng8
    Homme Profil pro
    Doctorant en Informatique
    Inscrit en
    Septembre 2010
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Doctorant en Informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 677
    Points : 997
    Points
    997
    Par défaut
    3/ Tu déclares char* argv[].
    Lorsque j'ai appris le C, j'ai toujours vu char** argv.
    Et d'ailleurs, je n'ai pratiquement vu que la seconde déclaration.

    Je conçois que les deux déclarations sont identiques à un qualificateur const (non discriminant) près.
    j'ai fini par me dire que c'était plus logique d'utiliser une syntaxe de « tableau » pour désigner la « liste » des arguments du programme.
    Mais, notamment après avoir remarqué que Qt utilise un char** pour le constructeur de QCoreApplication qui récupère les arguments de la ligne de commande, j'ai laissé tomber.

    Je me doute bien que c'est un autre débat, et je ne serais pas étonné qu'il aie déjà eu lieu.
    Mais je me demandais s'il n'existait pas une recommandation officielle pour cette question.
    char** argv ou char* argv[] ?

  16. #16
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Points : 4 551
    Points
    4 551
    Par défaut
    Citation Envoyé par Steph_ng8 Voir le message
    Euh... on parle bien de std::map ?
    Depuis quand ça se base sur une table de hachage ?
    Il me semblait plutôt que ça se basait sur un ordre strict.
    La table de hachage, c'est std::unordered_map, non ?
    À condition d'avoir un compilateur qui supporte le C++0x...
    Ou le TR1, puisque la classe existe aussi sous le nom std::tr1::unordered_map (ça augmente nettement son support).

    Et tu as raison: std::map est basé sur un arbre (un RB-tree, la plupart du temps). Les complexités de l'insertion et de la recherche sont en O(n.log(n)) (idem pour multimap, set, multiset).

    Citation Envoyé par Steph_ng8 Voir le message
    Je me doute bien que c'est un autre débat, et je ne serais pas étonné qu'il aie déjà eu lieu.
    Mais je me demandais s'il n'existait pas une recommandation officielle pour cette question.
    char** argv ou char* argv[] ?
    char* argv[] d'après la norme, section 3.6.1§2. D'après ce paragraphe, le compilateur doit accepter au moins les deux formes suivantes :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    int main(int argc, char *argv[])
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  17. #17
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Citation Envoyé par Steph_ng8 Voir le message
    Ceci dit, je remarque que ton « proto » ne parse pas les arguments de la ligne de commande, mais cherche les options disponibles dans les arguments de la ligne de commande.
    Ce n'est pas tout à fait pareil : non seulement tu passes sous silence les options non supportées (ce qui peut être voulu), mais en plus tu ne récupères pas les paramètres qui ne nécessitent pas d'étiquette (comme le nom du répertoire dans lequel se déplacer pour la commande cd).
    C'est exact, j'ai fait au plus simple juste pour montrer comment une classe peut se charger de ce rôle sans en prendre un autre.

    Citation Envoyé par Steph_ng8 Voir le message
    1/ D'où vient le préfixe « i- » sur les paramètres de tes fonctions ?
    Il a une signification particulière ?
    Je suppose que c'est pour les différencier des variables membres et des variables locales, mais je demande à tout hasard.
    Je met "i" pour "input". C'est une petite convention perso.
    Find me on github

  18. #18
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 614
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 614
    Points : 30 626
    Points
    30 626
    Par défaut
    Citation Envoyé par Steph_ng8 Voir le message
    [Edit]Et en plus, je ne suis pas à l'aise pour écrire des fonctions de hachage...[/Edit]
    Un petit coup de collate, peut etre
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

Discussions similaires

  1. $_POST : supprimer les paramètres passés par l'url
    Par yosraisi dans le forum Langage
    Réponses: 4
    Dernier message: 21/04/2008, 12h19
  2. Récupérer les paramètres passés en commande
    Par zuzuu dans le forum Windows
    Réponses: 13
    Dernier message: 13/03/2008, 18h23
  3. Réponses: 11
    Dernier message: 06/09/2006, 12h48
  4. [C#] - Récupérer les paramètres passés à une application
    Par linuxludo dans le forum Windows Forms
    Réponses: 4
    Dernier message: 14/11/2005, 14h41
  5. Réponses: 4
    Dernier message: 04/07/2003, 19h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo