Méthodologie include header

Bonjour,

J'ai crée une petite librairie statique (C++) qui encapsule FMODEX, pour l'instant la librairie comporte juste une classe. Dans le .h de cette classe j'inclus donc le header de fmod à savoir "fmod.hpp" (version C++).

Le problème arrive quand je veux utiliser cette librairie dans mon projet principal : quand j'inclus le header de la librairie, il essaye d'inclure le header de fmod et ne le trouve bien entendu pas car je n'ai pas rajouté le path vers fmod dans mon projet principal.

Ceci est un example... On voit bien que la méthodologie employée ici n'est pas correcte. J'avais déjà contourné le problème auparavant en mettant les includes (de fmod dans ce cas) dans les .cpp (de la lib statique dans ce cas) mais je ne pense pas que sa soit la solution optimale, de plus j'ai besoin de l'include dans mon header pour déclarer des attributs...

J'espère que vous avez compris la situation. J'ai un peu de mal a trouver une solution sur google ne sachant pas quels mots clé utiliser.

Salut,

Il n'y a, malheureusement, pas trente-six solutions...

Si tu inclues dans un de tes fichiers d'en-tête, un fichier d'en-tête issu d'une bibliothèque tierce, tu crées de facto une dépendance forte vis à vis de cette bibliothèque.

La conséquence immédiate sera que, si tu crées toi-même une bibliothèque, tu obligera celui qui l'utilisera à... disposer de cette bibliothèque tierce :aie:

Ceci dit, une déclaration anticipée des classes et fonctions de la bibliothèque tierce peut suffire dans certaines conditions, et avec certaines réserves.

Si donc tu ne fournis qu'une version compilée de ta bibliothèque, tu peux, peut-être, arriver à t'en sortir en créant les déclarations anticipées qui te sont nécessaires et en incluant les fichiers d'en-tête de la bibliothèque tierce dans les fichiers d'implémentation ;)

Mais, quoi qu'il en soit, cela ne fera pas "disparaitre" pour autant la dépendance de ton projet avec la bibliothèque tierce lors de la compilation, et tu devra donc veiller à indiquer le chemin à utiliser pour accéder aux fichiers d'en-tête de cette dernière et, à l'éditeur de lien, celui permettant d'accéder... au fichier binaire ( .a, .lib, .dll, .so....) de celle-ci

Merci pour cette réponse, effectivement j'attentai surement un miracle mais sa n'existe pas en programmation malheureusement !
Donc en effet si je suis obligé de référencer la bibliothèque utilisée niveau encapsulation c'est un peu moyen... Je pense que je vais quand même faire comme sa si c'est la seule solution.

Pour les déclarations anticipées j'avoue que je ne comprend pas toutes les implications notamment si on fait une déclaration anticipée dans le header de la librairie on aura par exemple si j'ai bien compris :

Code:

---

1 2 3 4

//malib.h (header public)   class MaClasse;

---

Code:

---

1 2 3 4 5 6 7 8

//malibdef.h (header privé) #include libencapsulée (ici fmod)   class MaClasse { ... // definition de la classe };

---

Code:

---

1 2 3 4 5 6

//malib.cpp #include malib.h #include malibdef.h   //definition des méthodes

---

Comment le projet tiers utilisant cette lib peut-il connaître les méthodes de la classe en ne connaissant que le header public ?

EDIT : peut être en définissant les méthodes dans le header public et les attributs + méthodes nécessitant des types définis dans la librairie encapsulée (fmod) dans le header privé ?

En fait, les restrictions que tu as au niveau des déclarations anticipées sont, finalement, assez peu nombreuses:

1. tu ne peux travailler (en attente du fichier dans lequel est effectivement inclus le fichier d'en-tête relatif à la classe déclarée anticipativement) qu'avec des pointeurs ou des références sur la classe déclarée anticipativement
2. Tu ne peux (en attendant toujours l'inclusion du fichier) absolument pas essayer d'accéder au contenu de la classe

Il y a une dérogation lorsque tu travailles avec des template, mais c'est surement déjà assez compliqué comme cela, sans que je vienne, en plus, t'embrouiller la tête sur le sujet :D

L'idée est donc de travailler sous une forme proche de
MaClass.hpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

//Le garde anti inclusion "classique" #ifndef MACLASS_HPP #define MACLASS_HPP // la déclaration anticipée de la classe issue de fmod class LaClassFmod; // la définition de ma classe à moi class MaClass { public: //les définitions des fonctions se font dans le *.cpp obligatoirement MaClass(ClassFmod *): // c'est un pointeur, c'est bon :D ClassFmod & get(); // on peut renvoyer une référence (constante ou non) void foo(); // une fonction qui manipule ClassFmod private: ClassFmod * ptr; // un membre doit être soit un pointeur soit une // référence (attention à la durée de vie :D) }; #endif // la fin du garde anti inclusion multiple

---

MaClass.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

//nécessaire pour connaitre la définition de MaClass #include <MaClass.hpp> // nécessaire pour connaitre la définition de ClassFmod #include <laclassfmod.hpp> // Le constructeur, pas de quoi casser trois pattes à un canard :D MaClass::MaClass(ClassFMod * p):ptr(p){} // l'accesseur, non plus :D ClassFmod & MaClass::get(){return *ptr;} // Pour foo, il faut connaitre le contenu de ClassFmod... // Ca tombe bien, on a inclus le fichier dans lequel se trouve la définition :D void MaClass::foo() { /* ... */ ptr->desPommes(); ptr->desPoires(); ptr->etDesScouBidouBidou(); ptr->wouah(); /* ... */ }

---

Salut,
Une autre approche est de différencier l'interface proposée par ta bibliothèque des détails d'implémentations effectif par l'utilisation du pimpl-idiom conjuguée à la déclaration anticipée : cf ici.

Salut, d'après ce que je vois les 2 méthodes proposées sont à peu près équivalentes.

J'ai implémenté le pimpl idiom et maintenant je n'ai en effet plus besoin d'inclure le header de fmod ni le .lib dans mon projet principal. Sa me convient donc parfaitement :ccool:.

Merci à vous :)