code dans hpp = pb dans lib?

Bonjour,

Je dois utiliser du code fait par quelqu'un, qu'on appelera Robinson, et je me dis que j'aimerais faire une lib de son code, que je ne modifie pas, pour ne pas avoir à le recompiler à chaque fois je fais un nouveau projet.

Cependant, tout son code est fait dans les points hpp. Si je fais une lib, je devrai faire des includes des hpp de Robinson dans mon code pour l'utiliser et mon code contiendra alors l'implémentation des classes de la lib.

Il y a donc un problème si le code est de Robinson est compilé lorsque je compile mon code, ce qui parait probable.

Est ce quelqu'un sait si c'est bien le cas?

Merci d'avance!

Salut,

Il faudrait déjà avoir une idée de ce qu'est le code qui se trouve dans les fichiers d'en-tête...

Par exemple, il est normal que le code relatif à des fonctions (membre de classe) template se trouve dans un fichier d'en-tête, pour la simple et bonne raison que... le compilateur en a besoin pour créer le code exécutable (binaire) adapté au type qui utilisé.

Ceci dit, une classe ou une fonction template ne sera de toutes manières pas compilé (hormis cas particulier) et n'apparaitra donc pas dans le contenu (binaire) de la bibliothèque :P

Si le code qui se trouve dans un fichier d'en-tête correspond à une classe "classique", l'implémentation des fonction sera sans doute donnée directement au sein de la définition de la classe.

Or, les fonctions implémentée dans la définition de la classe sont réputée implicitement déclarées inline, et on peut se retrouver dans une situation similaire à celle des fonctions (membres de classes) template.

Cependant, qu'il soit implicite ou non, le mot clé inline ne fait que demander au compilateur de remplacer l'appel d'une fonction par le code de celle-ci (il y a une discussion sur l'utilité actuelle des fonctions inline sur le forum, je te laisse le soin de la rechercher ;)), et il reste "seul maître à bord" quand il s'agit de décider s'il agit effectivement de la sorte ou non :P

Dans tous les autres cas, je serais déjà presque surpris que tout fonctionne sans problème, sans même commencer à créer une bibliothèque (sans compter sur le fait qu'il faut encore voir quel type de bibliothèque tu envisage de créer (statique ou dynamique :question:) ), mais on ne pourrait, de toutes manières, pas vraiment en dire plus avec les informations que tu nous donnes :P

Pourrais tu donc nous montrer un exemple de fichier auquel tu est confronté :question:

Je ne demande pas que tu nous présente le code de l'ensemble des fichiers d'en-tête, loin de là, mais si tu pouvais nous donner le code intégral de l'un des plus représentatifs, nous aurions très certainement plus facile à te répondre :D

Citation:

---

Or, les fonctions implémentée dans la définition de la classe sont réputée implicitement déclarées inline

---

Tu veux dire qu'avec le code suivant, il y a beaucoup de chances que le compilateur utilise Demarer comme une fonction inline alors que je n'ai pas mis inline devant?!?

Code:

---

1 2 3 4 5 6

class Voiture { Voiture(){}   Demarer(){ // blabla } }

---

Citation:

---

Dans tous les autres cas, je serais déjà presque surpris que tout fonctionne sans problème

---

Tu penses qu'un .hpp de la forme suivante ferait planter la compilation? C'est vrai que ça devrait faire une redéfinition de la fonction Voiture::demarer lorsque le .hpp est inclus dans un .cpp, alors qu'il a déjà été inclus dans un autre .cpp.

Code:

---

1 2 3 4 5 6 7 8

class Voiture { Voiture(){}   Demarer(); }   Voiture::Demarer(){ // blabla }

---

Citation:

---

Envoyé par nonozor

Tu veux dire qu'avec le code suivant, il y a beaucoup de chances que le compilateur utilise Demarer comme une fonction inline alors que je n'ai pas mis inline devant?!?

Code:

---

1 2 3 4 5 6

class Voiture { Voiture(){}   Demarer(){ // blabla } }

---

---

C'est exactement cela :D

Du moins, c'est ce que j'ai en tête, sans avoir été fouiller dans la norme pour voir ce qu'elle en dit :P

Citation:

---

Tu penses qu'un .hpp de la forme suivante ferait planter la compilation? C'est vrai que ça devrait faire une redéfinition de la fonction Voiture::demarer lorsque le .hpp est inclus dans un .cpp, alors qu'il a déjà été inclus dans un autre .cpp.

Code:

---

1 2 3 4 5 6 7 8

class Voiture { Voiture(){}   Demarer(); }   Voiture::Demarer(){ // blabla }

---

---

Pas la compilation en tant que telle, mais bien (et très certainement) l'édition de liens...

Chaque unité de compilation étant compilée séparément, tu as de grandes chances pour que les gardes anti inclusion multiples suffisent pour éviter les problèmes que pourrait poser le fait d'avoir un fichier d'en-tête inclus plusieurs fois du fait des inclusions en cascades, mais tu aurais une implémentation de Demarrer() (pour garder ton exemple) dans chaque unité de compilation dans laquelle voiture.h(pp) serait inclus, et ce, que ce soit de manière directe ou indirecte.

Au final, lorsqu'il s'agira de regrouper les différents fichiers objet ( *.o / *.obj, selon le compilateur) en un seul et même fichier, l'éditeur de liens poussera fatalement de hauts cris dus à l'ambigüité des symboles (il ne saura pas déterminer s'il doit lier avec Voiture::Demarrer qui se trouve dans XXX.o ou avec Voiture::Demarrer qui se trouve dans YYY.o).

l'iso C++ , page 106, 7.1.2, dit

Citation:

---

A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline
specifier indicates to the implementation that inline substitution of the function body at the point of call is
to be preferred to the usual function call mechanism. An implementation is not required to perform this
inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected.
A function defined within a class definition is an inline function. The inline specifier shall not appear
on a block scope function declaration.

---

On dirait donc que quand une fonction est définie dans une définition de classe, elle est forcément inline. Par contre, une fonction inlinée hors de la définition de classe n'est pas forcément inlinée.

Ainsi, avec l'exemple suivant, Demarer pourrait ne pas être inlinée, être compilé dans différentes unités de compilation, ce qui créerai un des ambiguités lors de l'édition de lien???

Code:

---

1 2 3 4 5 6 7 8

class Voiture { Voiture(){}   Demarer(); }   inline Voiture::Demarer(){ // blabla }

---

Citation:

---

Envoyé par nonozor

Ainsi, avec l'exemple suivant, Demarer pourrait ne pas être inlinée, être compilé dans différentes unités de compilation, ce qui créerai un des ambiguités lors de l'édition de lien???

Code:

---

1 2 3 4 5 6 7 8

class Voiture { Voiture(){}   Demarer(); }   inline Voiture::Demarer(){ // blabla }

---

---

Non, ca, c'est le "cas peau de banane" :P

Lorsque tu utilise le mot clé inline,ou lorsqu'une fonction est implicitement réputée inline (parce que définie directement dans la définition d'une classe), tu demande au compilateur de remplacer l'appel de la dite fonction par... les instructions qu'elle contient.

Sauf que tu ne fait que demander, et que le compilateur peut parfaitement décider de ne pas le faire, généralement parce que le d'instruction processeur (quelle que soit la durée réelle des instructions) est supérieure à une limite donnée, ou parce qu'il lui est impossible de l'inliner (comme c'est par exemple le cas des fonctions récursives, pour lesquelles il est impossible de savoir à l'avance le nombre d'occurrences nécessaires pour atteindre le cas de base).

Dans ce cas, il n'y a pas remplacement effectif de l'appel par les instructions de la fonction, mais la fonction est considérée par l'éditeur de lien exactement comme si le remplacement avait bel et bien eu lieu.

Il ne s'étonnera donc pas de trouver plusieurs implémentations de la fonction dans différentes unités de compilation (en fait, une implémentation dans chaque unité de compilation incluant le fichier d'en-tête de manière directe ou indirecte)

C'est ca, l'effet Kiss Cool :D