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 :

Bonnes pratiques dans les en-têtes


Sujet :

C++

  1. #1
    Rédacteur/Modérateur

    Avatar de Jiyuu
    Homme Profil pro
    Développeur amateur
    Inscrit en
    janvier 2007
    Messages
    2 456
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur amateur
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2007
    Messages : 2 456
    Points : 6 786
    Points
    6 786
    Billets dans le blog
    15
    Par défaut Bonnes pratiques dans les en-têtes
    à tous,

    Me mettant doucement à Qt version C++, je me pose une question sur une bonne pratique concernant la conception des fichiers d'entête, notamment dans le cas de l'interaction entre le code C++ et QML.

    Afin de pouvoir accéder aux fonctions C++ depuis le code QML il y a deux solutions possibles :
    • ajouter le "tag" Q_INVOKABLE" ;
    • ou mettre la fonction dans public slots.


    Question : Quelle différence entre ces deux méthodes, et pourquoi préférer l'une à l'autre.


    Tant que je suis dans les bonnes pratiques dans les headers, voici une autre question plus C++ que QML, mais qui devrait trouver réponse ici.

    Jusqu'à présent, voici un exemple de ce que je fais pour définir et utiliser une fonction :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    // Fichier .h
    void test (QString, int)
     
    // Fichier .cpp
    void test (QString toto, int a)
    À priori ça fonctionne puisque je n'ai pas d'erreur de compilation.

    Cependant, je remarque que souvent la déclaration dans le .h comprends aussi les "noms" des variables ce qui donnerait dans le cas présent :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    // Fichier .h
    void test (QString toto, int a)
    Même question que précédemment : Qu'est ce qui est le mieux, il y a t-il une grosse différence dans ces deux utilisations (performance, sécurité, ... ???)

    D'avance merci pour vos conseils.


    ++


    J
    Initiation à Qt Quick et QML : Partie 1 - Partie 2
    En cas de besoin, pensez à la
    Mon site et mes tutoriaux sur Developpez.com
    Pas de question technique par MP... Les forums sont là pour ça

  2. #2
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 165
    Points : 4 605
    Points
    4 605
    Par défaut
    Citation Envoyé par Jiyuu Voir le message
    Tant que je suis dans les bonnes pratiques dans les headers, voici une autre question plus C++ que QML, mais qui devrait trouver réponse ici.

    Jusqu'à présent, voici un exemple de ce que je fais pour définir et utiliser une fonction :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    // Fichier .h
    void test (QString, int)
     
    // Fichier .cpp
    void test (QString toto, int a)
    À priori ça fonctionne puisque je n'ai pas d'erreur de compilation.

    Cependant, je remarque que souvent la déclaration dans le .h comprends aussi les "noms" des variables ce qui donnerait dans le cas présent :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    // Fichier .h
    void test (QString toto, int a)
    Même question que précédemment : Qu'est ce qui est le mieux, il y a t-il une grosse différence dans ces deux utilisations (performance, sécurité, ... ???)
    Oui, ça fonctionne bien sans le nom dans les déclarations car le compilateur n'en a absolument pas besoin.

    L'intérêt de le mettre est documentaire.

    En effet d'une part le nom des paramètres participe complétement à la documentation de la fonction.
    Et d'autre part il est préférable avoir cette documentation dans les en-tête plutôt que dans les sources pour plusieurs raisons :
    • L'en-tête est toujours présente même lors de la livraison, même d'une version compilée.
    • L'en-tête contient (ou devrait contenir) uniquement l'interface et non l'implémentation, en tant qu'utilisateur d'une API, je me réfère donc à l'en-tête et non aux sources.

  3. #3
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 711
    Points : 4 417
    Points
    4 417
    Par défaut
    Hello,

    Sans oublier que les IDEs vont chercher les infos dans le .h pour l'auto-complétion (mais aussi pour donner de la doc sur la fonction : rôle / utilisation / etc...).
    La doc (format Doxygen ou autre) doit donc être présente dans le .h et non dans le .cpp.

    Il est aussi possible que les noms de paramètres diffèrent entre le .h et .cpp, par exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    // Fichier .h
    void test(QString fileName, int foo_notUsed);
     
    // Fichier .cpp
    void test(QString fileName, int) {
       // si le 2eme paramètre n'est pas utilisé, pas besoin de le nommer
       // on le nomme dans le .h simplement pour expliquer son rôle :
       // ici un paramètre qui était utile lors d'une version précédente
       // mais qui ne l'est plus (et qui reste pour ne pas casser le code)
       // ou un paramètre pas encore utilisé mais qui le sera lors d'une
       // prochaine version
       // (un QString ça ne se passe pas par ref constante habituellement ?)
    }

  4. #4
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2007
    Messages
    5 154
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 5 154
    Points : 16 968
    Points
    16 968
    Par défaut
    Je suis d'accord avec ces réponses.

    Il y a quand même des cas où l'information n'est pas nécessaire.
    En général, quand on aurait tendance à appeler les arguments a et b.
    Par exemple, un somme de vecteurs (mathématique), un produit matriciel, ou concaténation de chaine ou autre opérations mathématiques.

    Je ne trouverai pas moyenne(T, T) moins lisible que moyenne(T a, T b).

    J'irai plus loin avec l'exemple d'Iradrille:
    Si un paramêtre est nommé mais non utilisé dans la définition d'une fonction, cela peut lever un warning (gcc: unused parameter)
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  5. #5
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2008
    Messages : 1 505
    Points : 2 798
    Points
    2 798
    Par défaut
    En ce qui concerne slot / vs Q_INVOKABLE, la différence est qu’une méthode Q_INVOKABLE*pourra être appelée depuis QML, mais pas utilisée dans un connect côté C++, contrairement à un slot.

    Sinon, pour répondre à Iradrille, les QString sont implicitement partagés. Donc Qt utilise partout la copie et non le const& (c’est en particulier important pour les paramètres des slots, puisqu’ils peuvent être invokés de manière asynchrone).

Discussions similaires

  1. Bonne pratiques concernant les dataset
    Par bilou972 dans le forum Général Dotnet
    Réponses: 2
    Dernier message: 14/10/2008, 19h27
  2. [DatePicker] Bonne intégration dans les controles standards
    Par anthyme dans le forum Windows Presentation Foundation
    Réponses: 4
    Dernier message: 17/07/2008, 13h43
  3. Bonnes pratiques sur les versions de Java et JDK
    Par JPDMJC dans le forum Général Java
    Réponses: 4
    Dernier message: 20/12/2007, 15h52
  4. [Débutant] Bonnes pratiques avec les exceptions
    Par scougirou dans le forum Langage
    Réponses: 1
    Dernier message: 08/08/2007, 20h18
  5. [log4j][débutant] Bonnes pratiques avec les threads ?
    Par scougirou dans le forum Logging
    Réponses: 1
    Dernier message: 13/07/2007, 17h27

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