Discussion :

[NoIdea]

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

Code :

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

#include "B.hpp"

et B.inl

Code :

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

//Quelque chose

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.

[3DArchi]

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).

[NoIdea]

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.