Discussion :

[Invité]

Bonjour,

Pour le problème qui m'occupe, je code sous QtCreator et je compile avec MinGW sous Windows 7.

J'ai codé une petite librairie de mon cru, qui ne fait pas grand chose pour le moment, ainsi qu'un programme client pour utiliser et tester cette librairie.

Le problème est que lorsque je compile le programme client, j'ai plein de messages d'erreur (à l'édition des liens, je crois) : "undefined reference to '_imp__..."
Manifestement, il ne trouve pas les implémentations des fonctions de ma librairie.

En fait, après documentation, j'ai appris que pour utiliser une librairie dans ma configuration, deux fichiers sont nécessaires : le .dll et le .lib
Mais à la compilation de ma librairie, le .lib n'est jamais généré, et la raison semble en être du fait qu'il n'y a aucun fichier .cpp dans ce projet.

Seulement ma librairie n'utilise que des classes template, et pour cela, je suis obligé de placer les implémentations des fonctions dans le fichier .h, sinon ça ne fonctionne pas, d'où l'absence de fichier .cpp

Alors là, je suis face à un paradoxe : je dois mettre les implémentations de ma librairie dans les fichiers .h pour que les classes template fonctionnent mais en même temps je dois les mettre dans le fichier .cpp sinon le programme client ne les trouve pas à l'édition des liens.

Alors que puis-je faire ?

[ternel]

Une template n'a pas d'implémentation. Elle fournit au compilateur le modèle à utiliser pour créer les classes cibles.

L'intégralité de la définition du modèle doit être disponible. Il faut pour ca que tu mettes tout le code de la classe / fonction dans l'en-tête.
Ou dans des fichiers inclus par celui-ci, et que tu mettras aussi à disposition de l'utilisateur de la bibliothèque (ces fichiers seront utilisés comme des en-têtes)

[Bousk]

Salut,

c'est un cas de lib header-only, et c'est totalement correct. Boost en particulier est globalement dans ce cas

[imperio]

La traduction de library est bibliothèque, pas librairie (beaucoup se sont fait lyncher pour cette erreur ! ).

[koala01]

Salut,

Globalement, tu as deux possibilités :

Soit (c'est ce dont bousk a parlé), tu considères que ta bibliothèque est "header only", et tu fournis bel et bien l'implémentation de toutes tes fonctions dans les fichiers d'en-tête, et, dans ce cas, tu n'as absolument aucun besoin de générer une bibliothèque (encore moins une bibliothèque dynamique de type dll) : l'inclusion des fichiers d'en-tête suffira au compilateur pour générer le code spécifique à chaque fonction pour les différents types qui les utilisent.

Soit, tu sais que les différentes fonctionnalités de ta bibliothèques seront utilisées avec de types clairement prédéfinis et avec aucun autre. Dans ce cas, tu peux envisager la possibilité d'"expatrier" l'implémentation de tes fonctions dans des fichiers d'implémentation (*.cpp), mais il faut veiller à instancier explicitement toutes tes classes pour les types qu'elles doivent supporter.

Cette instanciation explicite te permettra de générer le code objet des différentes fonctions spécialisées pour les types que tu as clairement identifiés, et donc de générer une bibliothèque (qu'elle soit dynamique ou statique) que tu pourras utiliser pour l'édition de liens.

Après, il y a bien sur la solution "intermédiaire" qui consiste à instancier explicitement tes classes pour certains types tout en laissant la possibilité à l'utilisateur de ta bibliothèque d'utiliser tes classes avec d'autres types, mais cela devient assez compliqué à gérer

[Invité]

Merci pour vos réponses.

Donc, si j'ai bien compris, si je veux une bibliothèque partagée dynamique avec éditions des liens, je dois proposer une implémentation de mes classes template pour chaque type que peut prendre le template, ce qui, me semble-t-il détruit totalement l'intérêt du template.

Bon, ma bibliothèque sera donc header-only.

Merci pour vos lumière.

[koala01]

Merci pour vos réponses.

Donc, si j'ai bien compris, si je veux une bibliothèque partagée dynamique avec éditions des liens, je dois proposer une implémentation de mes classes template pour chaque type que peut prendre le template, ce qui, me semble-t-il détruit totalement l'intérêt du template.

Non, tu dois fournir une instanciation explicite de tes différentes classes. Par exemple, si tu as une classe template qui prend la forme (dans le fichier d'en-tête)de

Code :

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

1
2
3
4
template <typename T>
class MaClasse{
/* ... */
};

et que tu veux provoquer l'instanciation explicite pour tous les types primitifis, cela prendra la forme (dans le fichier d'implémentation) de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <MaClasse.hpp>
template MaClasse<char>;
template MaClasse<unsigned char>;
template MaClasse<short>;
template MaClasse<unsigned short>;
template MaClasse<int>;
template MaClasse<unsigned int>;
template MaClasse<long>;
template MaClasse<unsigned long>;
template MaClasse<long long>;
template MaClasse<unsigned long long>;
template MaClasse<float>;
template MaClasse<double>;
template MaClasse<long double>;

Comme tu peux le constater, cela ne demande qu'une seule ligne par type de donnée pour laquelle tu veux instancier ta classe, ce qui ne t'empêche absolument pas d'implémenter les fonctions de ta classes de manière générique.

La grosse différence est que tu "force" à l'utilisation de certains types (sans doute parce qu'il n'y a de toutes manières aucun sens à permettre l'utilisation d'autres spécialisations de ta classe ) et que, du coup, tu n'es plus obligé de veiller à ce que l'implémentation des fonctions de ta classe soient accessibles au départ des fichiers d'en-tête ce qui, dans certaines circonstances, pourra sans doute améliorer les temps de compilation.

Cependant, cette technique n'est, effectivement, utilisable que si tu arrives effectivement à définir quels sont les types qui pourront être utilisés comme spécialisation de ta classe car, si tu oublies un instanciation explicite, la spécialisation oublié est rendue indisponible

Bon, ma bibliothèque sera donc header-only.

Il y a moyen de faire sans, mais c'est effectivement sans doute la meilleure chose à faire malgré tout