Erreur de lien sur templates

Version imprimable

03/04/2006, 19h13
Herode

Erreur de lien sur templates
Bonjour à tous,
ça fait un bail que je n'ai pas joué avec les templates, et je me retrouve avec une erreur de lien (et un trou de mémoire :oops: ).
Le .h ressemble à ceci :
Code:

1 2 3 4 5 template< class T > class CNTree {...}; template< class T > std::ostream& operator << ( std::ostream& ostr, const CNTree< T >& rhs ) { ... }
Les garde d'include sont en place.
Le compilateur me dit :

Citation:

SynViewer6SingleDlg.obj : error LNK2005: "class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl operator<<(class std::basic_ostream<char,struct std::char_traits<char> > &,class CTreeItemHelper const &)" (??6@YAAAV?$basic_ostream@DU
?$char_traits@D@std@@@std@@AAV01@ABVCTreeItemHelper@@@Z) already defined in SynViewer6Single.obj

NB : la classe CSynViewer6SingleDlg a un membre de type CNTree< ... > of course.

Qu'ai-je donc oublié ? :?
03/04/2006, 21h41
loufoque

Les templates doivent être intégralement implementés dans le fichier d'entête, à moins que ton compilateur ne supporte la directive export (ce qui n'est pas le cas de MSVC)
03/04/2006, 22h01
Herode

Ils sont intégralement implémentés dans le .h. Le linker parle d'ailleurs de symboles déjà définis, et non pas de symboles manquants.
04/04/2006, 00h12
Luc Hermitte

Ce ne serait pas un problème de VC6 avec définition de l'opérateur ami à l'extérieur de la classe ?
04/04/2006, 09h10
Matthieu Brucher

Citation:

Envoyé par loufoque

Les templates doivent être intégralement implementés dans le fichier d'entête, à moins que ton compilateur ne supporte la directive export (ce qui n'est pas le cas de MSVC)

Et même dans ce cas, de toute manière, la directive export ne fait presque rien - il n'y a presque aucun compilateur qui la supporte tellement c'est difficle de la supporter, en plus sans aucun avantage par rapport à la solution habituelle -
Quel est ton compilateur ?
04/04/2006, 09h38
JolyLoic

Ce que tu dis est la propagande de certains développeurs de compilateurs qui ne supportent pas export...

Je te conseille la lecture de http://www.bourguet.org/cpp/export.pdf
04/04/2006, 10h17
Matthieu Brucher

C'est vrai que depuis que Stutter est chez Microsoft, on peut se poser des questions sur sa partialité, mais il y a 4 ans, seul le compilateur de Comeau supportait ce mot-clé. Depuis, qui le supporte en plus ?
De plus, un export, ça sert à quoi ? J'ai pas encore vu l'utilité, si tu as des infos - à part les temps de compilation -. Si j'ai bien compris, ça sert à n'avoir qu'une seule version de al fonction compilée, c'est ça ? Donc il faut que dans une unité de compialtion, il y ait tout et dans les autres rien, mais avec le bon type de données ?
Enfin, si tu as des infos plus précises que le pdf - très bien, d'ailleurs, merci Jean-Marc ;) -, je suis preneur et si tu me fais changer d'avis, c'est encore mieux :D
04/04/2006, 13h16
loufoque

Citation:

De plus, un export, ça sert à quoi ?

À pouvoir compiler différentes parties d'un programme en tant que modules indépendants.
La même utilité que de séparer déclarations et définitions pour les classes et fonctions, ce que tu fais déjà probablement.

En C++0x il y aura de vrais modules, et là le support de export sera indispensable.

(export est aussi supporté par ICC)
04/04/2006, 13h46
adel_dz

Tes fonctions inline ne sont pas inline (omission du keyword inline):
template<typename Ty>
inline //ceci est manquent
R
MaClass<Ty>::Func() {.../..}
04/04/2006, 14h16
Matthieu Brucher

Normalement, on n'est pas obligé de mettre un inline - qui n'est qu'une indication pour le compilateur - pour cet opérateur, ce n'est pas un maClass& maClass::operator<<(...)
04/04/2006, 14h18
adel_dz

Citation:

Envoyé par Miles

Normalement, on n'est pas obligé de mettre un inline - qui n'est qu'une indication pour le compilateur - pour cet opérateur, ce n'est pas un maClass& maClass::operator<<(...)

Vas dire ca au compilateur de MS
04/04/2006, 14h26
Matthieu Brucher

Ben je n'ai eu aucun problème avec lui pour des choses de ce genre, bizarre...
04/04/2006, 15h02
Herode

Oups, j'ai du rater des mails signalant les réponses :?

Citation:

Envoyé par Luc Hermitte

Ce ne serait pas un problème de VC6 avec définition de l'opérateur ami à l'extérieur de la classe ?

C'est bien VC6 et un opérateur ami défini (forcément) hors de la classe. Je déduis de ta question que VC6 est boggué sur ce point ?

Citation:

Envoyé par adel_z

Tes fonctions inline ne sont pas inline (omission du keyword inline):

inline n'est pas obligatoire, comme le signale Miles plus bas. J'ai tout de même essayé avec, mais le résultat est le même...
04/04/2006, 15h57
Matthieu Brucher

Oui, VC6 est un très mauvais compilateur pour les templates et autres. Tu ne peux pas changer de compilateur pour une version plus récente ?
04/04/2006, 16h26
Herode

Je crains de n'avoir guère le choix des outils... C'est ça ou .NET 2002, qui plante quand j'insère le contrôle ActiveX avec lequel je travaille (un DWFViewer d'Autocad). .NET 2005 n'est - paraît-il - pas compatible avec d'autres libs d'Autocad (ou pas encore...), donc pas disponible ici sur les postes de développement.
04/04/2006, 16h29
Herode

Je crains de n'avoir guère le choix des outils... C'est ça ou .NET 2002, qui plante quand j'insère le contrôle ActiveX avec lequel je travaille (un DWFViewer d'Autocad). .NET 2005 n'est - paraît-il - pas compatible avec d'autres libs d'Autocad (ou pas encore...), donc pas disponible ici sur les postes de développement.

Cela dit, j'ai contourné le problème en passant par une méthode interne ToString() à-la-Java. En attendant mieux, mais ce n'est pas bien grave sur ce projet précis.

Merci pour les infos en tout cas, ça me remet un peu dans le bain :)
04/04/2006, 17h03
Matthieu Brucher

:|
Problématique... Et VS2003 ? Tu peux garder l'IDE de VS2002 et changer le compilateur - qui est gratuit -
04/04/2006, 17h51
JolyLoic

Citation:

Envoyé par loufoque

En C++0x il y aura de vrais modules

Je l'espère, mais rien n'est moins sur... De l'aveu même de l'auteur de la proposition, celle si n'est pas encore aboutie, et il n'est pas certain qu'elle avance suffisemment vite pour être dans C++0x.
04/04/2006, 22h29
loufoque

C'est pourtant listé dans la catégorie des sujets actifs dans l'évolution

Citation:

These topics are still actively being developed, and there is a clear intention to incorporate each one in the next standard.

Après bon c'est toujours possible que ce ne soit pas intégré.
05/04/2006, 00h16
Matthieu Brucher

Il y a tellement de choses qui était prévues pour le standard en 2003 et qui est passé à la trappe :(
05/04/2006, 02h06
Luc Hermitte

Citation:

Envoyé par Herode

Oups, j'ai du rater des mails signalant les réponses :?

;) cela arrive facilement.

Citation:

Citation:

Envoyé par Luc Hermitte

Ce ne serait pas un problème de VC6 avec définition de l'opérateur ami à l'extérieur de la classe ?

C'est bien VC6 et un opérateur ami défini (forcément) hors de la classe. Je déduis de ta question que VC6 est boggué sur ce point ?

Je me souviens qu'il y en avait qui était buggué sur ce point, sans me souvenir duquel, bien qu'avec une forte présomption de culpabilité pour VC.

Et au fait, "ami" n'implique pas forcément de le définir en dehors de la déclaration de la classe. C'est même un peu la seule solution portable. Quitte à appeler une fonction membre qui sera définie plus loin.
05/04/2006, 10h24
Herode

Citation:

Et au fait, "ami" n'implique pas forcément de le définir en dehors de la déclaration de la classe. C'est même un peu la seule solution portable. Quitte à appeler une fonction membre qui sera définie plus loin.

Je ne connaissais pas cette possibilité. C'est toujours bon à savoir ! 8)

J'ai un problème similaire:
Code:

1 2 3 4 main.obj : error LNK2005: "public: void __thiscall ArbreCP::insererCode(char,char *)" (?insererCode@ArbreCP@@QAEXDPAD@Z) déjà défini(e) dans codeprefix.obj main.obj : error LNK2005: "protected: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall ArbreCP::retournerCode(char,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class NoeudArbre<char> *)" (?retournerCode@ArbreCP@@IAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@DV23@PAV?$NoeudArbre@D@@@Z) déjà défini(e) dans codeprefix.obj main.obj : error LNK2005: "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall ArbreCP::retournerCode(char)" (?retournerCode@ArbreCP@@QAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@D@Z) déjà défini(e) dans codeprefix.obj .\Debug/compress.exe : fatal error LNK1169: un ou plusieurs symboles définis à différentes reprises ont été rencontrés
En fait, j'ai par exemple une classe template Arbre où le .cpp est inclu dans le .h de la classe template Arbre.

Maintenant, j'ai une autre classe, CodePrefix qui elle a besoin d'un objet de type Arbre, donc j'inclus le fichier .h de la classe template Arbre dans mon fichier .h de la classe CodePrefix.

Maintenant, j'ai mon programme principal (la fonction main) qui est dans le fichier main.cpp.

Dans ce fichier, j'inclus le fichier codeprefix.h. C'est alors à ce moment que tout se met à planter ...!

Et je crois que je viens de résoudre mon problème... En fait, il fallait que j'enlève mon fichier .cpp de la classe codeprefix du projet... ?!?

Et ça fonctionne ! 8O

10/04/2006, 08h27
Yomane

Non en fait ça ne fonctionne pas du tout parce qu'à ce moment-là toutes les fonctions avec l'objet que j'utilise dans mon main qui proviennent de la classe CodePrefix n'est pas résolu :(

Code:

main.obj : error LNK2019: symbole externe non résolu "public: int __thiscall CodePrefix::ecritureFichier(void)" (?ecritureFichier@CodePrefix@@QAEHXZ) référencé dans la fonction _main

Comment me sortir de cet impasse ?!

***

EDIT:

J'ai finalement résolu mon problème, en fait, je traite ma classe CodePrefix comme si elle aussi était une classe template et alors je n'ai plus de problème ! C'est-à-dire que j'enlève le .cpp de mon projet pour le rajouter dans le .h de la même façon qu'avec mon .h de ma classe Arbre qui elle, est un template !

Quand même étrange d'avoir à faire ça non ?!
10/04/2006, 08h51
Matthieu Brucher

On ne peut pas trop t'aider juste en ayant les erreurs...
Si tu inclus dans ton header un cpp, change son nom en header.
Si c'est une classe template, c'est normal qu'on la mette en header, c'est toujours comme ça. En revanche, mets les fonctions de la classe en inline dans la classe et non pas dans un fichier à côté.
10/04/2006, 09h16
Yomane

Citation:

Envoyé par Miles

Si c'est une classe template, c'est normal qu'on la mette en header, c'est toujours comme ça.

Oui, ma classe Arbre, qui est un template, est définit dans un .h et le .cpp (la définition des fonctions membres de la classe) est inclu à la toute fin du fichier en faisant #include "arbre.cpp", avant le #endif (du #ifndef _ARBRE_H #define _ARBRE_H) comme cela est mentionné dans la FAQ !

Maintenant, ce que je me demande, c'est si une classe qui possède un objet d'une classe template doit elle aussi être mise en header, de la même façon que la classe template ? Parce que jusqu'à maintenant, c'est le seul moyen "légitime" que j'ai trouvé pour résoudre mon problème...
10/04/2006, 10h07
Herode
Hé bien, une classe qui possède un objet générique est elle-même une classe générique, non ?
Code:

1 2 3 4 5 template< class T> class G { [...] T member; };
10/04/2006, 10h32
Matthieu Brucher

Ben oui...