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 :

Le préprocesseur et .inl


Sujet :

C++

Vue hybride

NoIdea Le préprocesseur et .inl 02/11/2010, 17h16
3DArchi Eviter le plat de spaghetti... 02/11/2010, 20h18
NoIdea Si on prend un exemple : Ma... 02/11/2010, 21h00
Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé

    Profil pro
    Inscrit en
    Avril 2010
    Messages
    356
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2010
    Messages : 356
    Par défaut Le préprocesseur et .inl
    Bonjour à tous.
    Comment résoudre l'éternel problème des .inl ?
    Supposons deux classes A et B, templates ayant chacun un .hpp et un .inl
    On ne peut inclure A.inl à la fin de A.hpp car A.inl à besoin de B.hpp et que B.hpp doit inclure A.hpp.

    On a donc quelque chose comme sa :

    A.hpp
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    template<typename T>
    class B;
    template<typename T2>
    class A
    {
              private :
                   B*qqch;
    };
    B.hpp

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include "A.hpp"
     
    template<typename T>
    class B
    {
    };
    #include "B.inl"
    et A.inl

    et B.inl

    main.cpp

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include "A.hpp"
    #include "B.hpp"
    #include "A.inl"//On est obligé de l'inclure à la main
     
    int main()
    {
    }
    Ceci marche parfaitement mais oblige l'utilisateur à inclure les .inl "à la main"

    Imaginons maintenant un beaucoup plus gros projet. Il faut toujours inclure les .inl à la fin pour la même raison que ci dessus.

    On ne souhaite pas être obligé de choisir les .inl à inclure. On préfèrera un système ou l'on inclut inls.hpp après toutes les autres includes dans chaque .cpp

    Comment construire inls.hpp :

    On pourrait décider d'inclure tous les .inl (auquel cas, il faut inclure aussi tous les .hpp correspondant avant). Ceci est ce que je fais actuellement. Cependant, sa présente un défaut majeur : le temps de compilation. A chaque fois que je modifie un header, tous les .cpp sont recompilés même si ils en n'ont pas réellement besoin (du header modifié).
    Une autre solution que j'ai testée consiste à mettre des ifdef pour voir quels .inl je dois inclure. Me manque juste un GOTO préprocesseur pour que sa marche. je vous montre le fichier :

    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
    #define __ALLOW_INL_INCLUSION_OK__
    #ifdef BINDING_HPP_INCLUDED
    #include "Binding.inl"
    #endif
    #ifdef EVENEMENT_HPP_INCLUDED
    #include "Event.inl"
    #endif
    #ifdef EXCEPTIONS_HPP_INCLUDED
    #include "Exceptions.inl"
    #endif
    #ifdef EMITTABLE_HPP_INCLUDED
    #include "Emittable.inl"
    #endif
    #ifdef RECTANGLE_HPP_INCLUDED
    #include "Rectangle.inl"
    #endif
    #ifdef SORTED_HPP_INCLUDED
    #include "Sorted.inl"
    #endif
    #ifdef APPLICATION_HPP_INCLUDED
    #include "Application.inl"
    #endif
    #ifdef GRAPHICOBJECT_HPP_INCLUDED
    #include "GraphicObject.inl"
    #endif
    #undef __ALLOW_INL_INCLUSION_OK__
    Petit défaut : Application.inl inclut binding.hpp que personne d'autre n'inclut. Conséquence : Binding.inl n'est pas inclut !
    Moyen de résolution possible : A chaque fois que j'inclus un .inl, je reprends au départ (début du fichiers inls.hpp).
    Manque : Pas de GOTO avec le préprocesseur.

    Quelqu'un à une solution ?


    Merci.

  2. #2
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Citation Envoyé par NoIdea Voir le message
    Quelqu'un à une solution ?
    Eviter le plat de spaghetti Dit autrement, la présentation de ton problème m'amène spontanément à penser que soit ton design a un problème (toutes ces interdépendances sont suspectes) soit ton niveau d'interface n'est pas bon (tu exposes des détails d'implémentation et devrait avoir un .h plus global qui saurait comment organiser tes briques). Intuitivement, je penche quand même pour la première solution (interdépendances suspectes).

  3. #3
    Membre éclairé

    Profil pro
    Inscrit en
    Avril 2010
    Messages
    356
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2010
    Messages : 356
    Par défaut
    la présentation de ton problème m'amène spontanément à penser que soit ton design a un problème (toutes ces interdépendances sont suspectes)
    Si on prend un exemple : Ma classe Application possède un vector<GraphicObject*> qui sont les GraphicObject n'ayant pas de parent.
    Dans l'équivalent du .cpp, ici le .inl, je vais avoir besoin des méthodes de GraphicObject. Donc, Application.inl à besoin de Application.hpp et GraphicObject.hpp
    Pour les autres, il s'agit de chose similaires.

Discussions similaires

  1. Préprocesseur en C
    Par socrate dans le forum C
    Réponses: 4
    Dernier message: 06/09/2006, 16h39
  2. Flux et préprocesseur .
    Par Clad3 dans le forum C++
    Réponses: 19
    Dernier message: 17/07/2006, 18h21
  3. [\ifdefined] "Préprocesseur" en LaTeX ?
    Par Biosox dans le forum Programmation (La)TeX avancée
    Réponses: 3
    Dernier message: 12/06/2006, 15h24
  4. préprocesseur et lisibilité du code
    Par Thierry Chappuis dans le forum C
    Réponses: 12
    Dernier message: 07/02/2006, 13h58
  5. Réponses: 4
    Dernier message: 13/07/2004, 18h59

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