Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas
(ou plus exactement ne linke pas...)
est-ce un non respect de la norme ou de la syntaxe de ma part ou un
défaut d'implémentation des compilos ?
cordialement,
MP
#include <iostream>
//************************ classe de base ********************************
template <class T>
class ISeq
{
public:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...)
Ç'aurait été plus gentil si tu nous avais indiqué de quoi ils se plaignaient.
est-ce un non respect de la norme ou de la syntaxe de ma part ou un défaut d'implémentation des compilos ?
Je ne sais pas si c'est peut-être un problème de copier/coller, mais il manque bien une implémentation de l'opérateur d'affectation dans ISeq. Or dans Seq2, tu as deux opérateurs d'affectation, celui que tu as déclaré, et l'opérateur d'affectation de copie, déclarée : ISeq1& operator=( ISeq1 const& ) ; implicitement par le compilateur.
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le compilateur résoud le surcharge en faveur de l'affectation par copie (Seq1 étant une base de Seq2), et essaie donc de générer une implémentation implicitement aussi. Et c'est là que le bat blesse -- la version générée appelle les opérateurs d'affectation des classes de base.
Enfin, un commentaire plus général : la virtualité et l'affectation font mauvais menage. En fait, on ne peut pas changer le type de l'objet dans l'affectation. Le plus souvent, on préfère donc ne travailler qu'avec des pointeurs, et d'utiliser une fonction « clone »
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Mathieu Peyréga <peyrega@no.spam.please.netcourrier.com> wrote in
message news:<3F734EEF.1010206@no.spam.please.netcourrier.com>...
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas
(ou plus exactement ne linke pas...)
Ç'aurait été plus gentil si tu nous avais indiqué de quoi ils se
plaignaient.
est-ce un non respect de la norme ou de la syntaxe de ma part ou un
défaut d'implémentation des compilos ?
Je ne sais pas si c'est peut-être un problème de copier/coller, mais il
manque bien une implémentation de l'opérateur d'affectation dans ISeq.
Or dans Seq2, tu as deux opérateurs d'affectation, celui que tu as
déclaré, et l'opérateur d'affectation de copie, déclarée :
ISeq1& operator=( ISeq1 const& ) ;
implicitement par le compilateur.
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le
compilateur résoud le surcharge en faveur de l'affectation par copie
(Seq1 étant une base de Seq2), et essaie donc de générer une
implémentation implicitement aussi. Et c'est là que le bat blesse -- la
version générée appelle les opérateurs d'affectation des classes de
base.
Enfin, un commentaire plus général : la virtualité et l'affectation font
mauvais menage. En fait, on ne peut pas changer le type de l'objet dans
l'affectation. Le plus souvent, on préfère donc ne travailler qu'avec
des pointeurs, et d'utiliser une fonction « clone »
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...)
Ç'aurait été plus gentil si tu nous avais indiqué de quoi ils se plaignaient.
est-ce un non respect de la norme ou de la syntaxe de ma part ou un défaut d'implémentation des compilos ?
Je ne sais pas si c'est peut-être un problème de copier/coller, mais il manque bien une implémentation de l'opérateur d'affectation dans ISeq. Or dans Seq2, tu as deux opérateurs d'affectation, celui que tu as déclaré, et l'opérateur d'affectation de copie, déclarée : ISeq1& operator=( ISeq1 const& ) ; implicitement par le compilateur.
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le compilateur résoud le surcharge en faveur de l'affectation par copie (Seq1 étant une base de Seq2), et essaie donc de générer une implémentation implicitement aussi. Et c'est là que le bat blesse -- la version générée appelle les opérateurs d'affectation des classes de base.
Enfin, un commentaire plus général : la virtualité et l'affectation font mauvais menage. En fait, on ne peut pas changer le type de l'objet dans l'affectation. Le plus souvent, on préfère donc ne travailler qu'avec des pointeurs, et d'utiliser une fonction « clone »
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
DG
writes:
[...]
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le compilateur résoud le surcharge en faveur de l'affectation par copie (Seq1 étant une base de Seq2), et essaie donc de générer une implémentation implicitement aussi. Et c'est là que le bat blesse -- la version générée appelle les opérateurs d'affectation des classes de base.
Pour ma part, j'ai un peu de mal à comprendre là. Si je t'ai bien suivi, le compilateur génère implicitement l'implémentation suivante: ISeq1& operator=( ISeq1 const& );
et c'est cette implémentation qui est utilisée lors du « *pA = *pB » alors pourquoi a-t-on aussi besoin de d'une implémentation de l'opérateur d'affectation dans les classes de bases ? Est-ce que c'est le même mécanisme que lorsqu'une classe B hérite d'une classe A, lors de l'instanciation d'un objet de type B, la constructeur de A puis celui de B est appelé ?
kanze@gabi-soft.fr writes:
[...]
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le
compilateur résoud le surcharge en faveur de l'affectation par copie
(Seq1 étant une base de Seq2), et essaie donc de générer une
implémentation implicitement aussi. Et c'est là que le bat blesse -- la
version générée appelle les opérateurs d'affectation des classes de
base.
Pour ma part, j'ai un peu de mal à comprendre là. Si je t'ai bien suivi,
le compilateur génère implicitement l'implémentation suivante:
ISeq1& operator=( ISeq1 const& );
et c'est cette implémentation qui est utilisée lors du « *pA = *pB »
alors pourquoi a-t-on aussi besoin de d'une implémentation de
l'opérateur d'affectation dans les classes de bases ? Est-ce que c'est
le même mécanisme que lorsqu'une classe B hérite d'une classe A, lors
de l'instanciation d'un objet de type B, la constructeur de A puis
celui de B est appelé ?
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le compilateur résoud le surcharge en faveur de l'affectation par copie (Seq1 étant une base de Seq2), et essaie donc de générer une implémentation implicitement aussi. Et c'est là que le bat blesse -- la version générée appelle les opérateurs d'affectation des classes de base.
Pour ma part, j'ai un peu de mal à comprendre là. Si je t'ai bien suivi, le compilateur génère implicitement l'implémentation suivante: ISeq1& operator=( ISeq1 const& );
et c'est cette implémentation qui est utilisée lors du « *pA = *pB » alors pourquoi a-t-on aussi besoin de d'une implémentation de l'opérateur d'affectation dans les classes de bases ? Est-ce que c'est le même mécanisme que lorsqu'une classe B hérite d'une classe A, lors de l'instanciation d'un objet de type B, la constructeur de A puis celui de B est appelé ?
Christophe de Vienne
Mathieu Peyréga wrote:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...) est-ce un non respect de la norme ou de la syntaxe de ma part ou un défaut d'implémentation des compilos ?
[...]
//************************ classe de base ******************************** template <class T> class ISeq { public:
virtual ~ISeq(void) = 0;
Il me semble que les destructeurs doivent forcément avoir une implémentation, même si on ajoute '= 0' à la définition.
[...]
Seq1(void); ~Seq1(void); [...]
Seq2(void); ~Seq2(void);
Ou as-tu implémenté ces fonctions ? L'erreur au link ne serait pas qu'il manque les fonctions SeqX::SeqX et SeqX::~SeqX ?
A+
Christophe
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Mathieu Peyréga wrote:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas
(ou plus exactement ne linke pas...)
est-ce un non respect de la norme ou de la syntaxe de ma part ou un
défaut d'implémentation des compilos ?
[...]
//************************ classe de base ********************************
template <class T>
class ISeq
{
public:
virtual ~ISeq(void) = 0;
Il me semble que les destructeurs doivent forcément avoir une
implémentation, même si on ajoute '= 0' à la définition.
[...]
Seq1(void);
~Seq1(void);
[...]
Seq2(void);
~Seq2(void);
Ou as-tu implémenté ces fonctions ? L'erreur au link ne serait pas qu'il
manque les fonctions SeqX::SeqX et SeqX::~SeqX ?
A+
Christophe
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...) est-ce un non respect de la norme ou de la syntaxe de ma part ou un défaut d'implémentation des compilos ?
[...]
//************************ classe de base ******************************** template <class T> class ISeq { public:
virtual ~ISeq(void) = 0;
Il me semble que les destructeurs doivent forcément avoir une implémentation, même si on ajoute '= 0' à la définition.
[...]
Seq1(void); ~Seq1(void); [...]
Seq2(void); ~Seq2(void);
Ou as-tu implémenté ces fonctions ? L'erreur au link ne serait pas qu'il manque les fonctions SeqX::SeqX et SeqX::~SeqX ?
A+
Christophe
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Christophe de Vienne
Mathieu Peyréga wrote:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...)
Pourrais-tu être plus précis : quels sont les messages du linker ?
A+
Christophe
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Mathieu Peyréga wrote:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas
(ou plus exactement ne linke pas...)
Pourrais-tu être plus précis : quels sont les messages du linker ?
A+
Christophe
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...)
Pourrais-tu être plus précis : quels sont les messages du linker ?
A+
Christophe
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
peyrega
Il me semble que les destructeurs doivent forcément avoir une implémentation, même si on ajoute '= 0' à la définition.
Ou as-tu implémenté ces fonctions ? L'erreur au link ne serait pas qu'il manque les fonctions SeqX::SeqX et SeqX::~SeqX ?
A+
Christophe
c'est le cas... il sont implémentés si tu regardes le code fourni l'erreur se produit au link et est relative à la première instruction d'affectation du main
-- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Il me semble que les destructeurs doivent forcément avoir une
implémentation, même si on ajoute '= 0' à la définition.
Ou as-tu implémenté ces fonctions ? L'erreur au link ne serait pas qu'il
manque les fonctions SeqX::SeqX et SeqX::~SeqX ?
A+
Christophe
c'est le cas... il sont implémentés si tu regardes le code fourni
l'erreur se produit au link et est relative à la première instruction
d'affectation du main
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Il me semble que les destructeurs doivent forcément avoir une implémentation, même si on ajoute '= 0' à la définition.
Ou as-tu implémenté ces fonctions ? L'erreur au link ne serait pas qu'il manque les fonctions SeqX::SeqX et SeqX::~SeqX ?
A+
Christophe
c'est le cas... il sont implémentés si tu regardes le code fourni l'erreur se produit au link et est relative à la première instruction d'affectation du main
-- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
peyrega
Ç'aurait été plus gentil si tu nous avais indiqué de quoi ils se plaignaient.
erreur de link (unresolved sur l'opérateur ISeq::operator=)
Je ne sais pas si c'est peut-être un problème de copier/coller, mais il manque bien une implémentation de l'opérateur d'affectation dans ISeq.
c'est volontaire puisque c'est une classe d'interface et que l'opérateur est déclaré virtuel (autorisé par la norme pour l'opérateur =) Les implémentations sont respectivement dans Seq1 et Seq2 qui sont bien les classes concrètes instanciées
Or dans Seq2, tu as deux opérateurs d'affectation, celui que tu as déclaré, et l'opérateur d'affectation de copie, déclarée : ISeq1& operator=( ISeq1 const& ) ; implicitement par le compilateur.
Et qui ne fonctionne donc pas correctement puisqu'il apelle la mauvaise implémentation...
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le compilateur résoud le surcharge en faveur de l'affectation par copie (Seq1 étant une base de Seq2), et essaie donc de générer une implémentation implicitement aussi. Et c'est là que le bat blesse -- la version générée appelle les opérateurs d'affectation des classes de base.
Enfin, un commentaire plus général : la virtualité et l'affectation font mauvais menage. En fait, on ne peut pas changer le type de l'objet dans l'affectation. Le plus souvent, on préfère donc ne travailler qu'avec des pointeurs, et d'utiliser une fonction « clone »
ça pour faire mauvais ménage... -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Ç'aurait été plus gentil si tu nous avais indiqué de quoi ils se
plaignaient.
erreur de link (unresolved sur l'opérateur ISeq::operator=)
Je ne sais pas si c'est peut-être un problème de copier/coller, mais il
manque bien une implémentation de l'opérateur d'affectation dans ISeq.
c'est volontaire puisque c'est une classe d'interface et que l'opérateur
est déclaré virtuel (autorisé par la norme pour l'opérateur =)
Les implémentations sont respectivement dans Seq1 et Seq2 qui sont bien
les classes concrètes instanciées
Or dans Seq2, tu as deux opérateurs d'affectation, celui que tu as
déclaré, et l'opérateur d'affectation de copie, déclarée :
ISeq1& operator=( ISeq1 const& ) ;
implicitement par le compilateur.
Et qui ne fonctionne donc pas correctement puisqu'il apelle la mauvaise
implémentation...
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le
compilateur résoud le surcharge en faveur de l'affectation par copie
(Seq1 étant une base de Seq2), et essaie donc de générer une
implémentation implicitement aussi. Et c'est là que le bat blesse -- la
version générée appelle les opérateurs d'affectation des classes de
base.
Enfin, un commentaire plus général : la virtualité et l'affectation font
mauvais menage. En fait, on ne peut pas changer le type de l'objet dans
l'affectation. Le plus souvent, on préfère donc ne travailler qu'avec
des pointeurs, et d'utiliser une fonction « clone »
ça pour faire mauvais ménage...
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Ç'aurait été plus gentil si tu nous avais indiqué de quoi ils se plaignaient.
erreur de link (unresolved sur l'opérateur ISeq::operator=)
Je ne sais pas si c'est peut-être un problème de copier/coller, mais il manque bien une implémentation de l'opérateur d'affectation dans ISeq.
c'est volontaire puisque c'est une classe d'interface et que l'opérateur est déclaré virtuel (autorisé par la norme pour l'opérateur =) Les implémentations sont respectivement dans Seq1 et Seq2 qui sont bien les classes concrètes instanciées
Or dans Seq2, tu as deux opérateurs d'affectation, celui que tu as déclaré, et l'opérateur d'affectation de copie, déclarée : ISeq1& operator=( ISeq1 const& ) ; implicitement par le compilateur.
Et qui ne fonctionne donc pas correctement puisqu'il apelle la mauvaise implémentation...
Quand tu fais « *pA = *pB », tu affectes un Seq2 à un Seq1. Le compilateur résoud le surcharge en faveur de l'affectation par copie (Seq1 étant une base de Seq2), et essaie donc de générer une implémentation implicitement aussi. Et c'est là que le bat blesse -- la version générée appelle les opérateurs d'affectation des classes de base.
Enfin, un commentaire plus général : la virtualité et l'affectation font mauvais menage. En fait, on ne peut pas changer le type de l'objet dans l'affectation. Le plus souvent, on préfère donc ne travailler qu'avec des pointeurs, et d'utiliser une fonction « clone »
ça pour faire mauvais ménage... -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Rien n'empeche de definir un membre pur, c'est meme obligatoire pour le destructeur.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Rien n'empeche de definir un membre pur, c'est meme obligatoire pour
le destructeur.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Rien n'empeche de definir un membre pur, c'est meme obligatoire pour le destructeur.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
peyrega
virtual ~ISeq(void) = 0; C'est correct un destructeur virtuel pur ?
c'est autorisé par la norme
Surtout defini un peu plus loin.
et l'implémentation doit exister si on veut pouvoir instancier des classes dérivées -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
virtual ~ISeq(void) = 0;
C'est correct un destructeur virtuel pur ?
c'est autorisé par la norme
Surtout defini un peu plus loin.
et l'implémentation doit exister si on veut pouvoir instancier des classes
dérivées
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
virtual ~ISeq(void) = 0; C'est correct un destructeur virtuel pur ?
c'est autorisé par la norme
Surtout defini un peu plus loin.
et l'implémentation doit exister si on veut pouvoir instancier des classes dérivées -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
peyrega
Christophe de Vienne wrote:
Mathieu Peyréga wrote:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas (ou plus exactement ne linke pas...)
Pourrais-tu être plus précis : quels sont les messages du linker ?
Compiling... Main_test.cpp d:projetstest_geocalclibmain_test.cpp(67) : warning C4250: 'Seq2<double>' : inherits 'Seq1<double>::setValue' via dominance d:projetstest_geocalclibmain_test.cpp(49) : see declaration of 'setValue' d:projetstest_geocalclibmain_test.cpp(120) : see reference to class template instantiation 'Seq2<double>' being compiled d:projetstest_geocalclibmain_test.cpp(67) : warning C4250: 'Seq2<double>' : inherits 'Seq1<double>::getValue' via dominance d:projetstest_geocalclibmain_test.cpp(50) : see declaration of 'getValue' d:projetstest_geocalclibmain_test.cpp(120) : see reference to class template instantiation 'Seq2<double>' being compiled
La compilation ne pose donc de problèmes ni à Visual C++ 6.0 ni à gcc 3.3.1 en revanche, tout lesdeux échouent lors de l'édition des liens....
Pour la question d'un autre post du fil sur le destructeur, oui un destructeur peut être déclaré virtuel pur, et doit avoir une implémentation si on veux pouvoir instancier des classes dérivées c'est du moins ce que j'ai compris en regardant la norme. -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Christophe de Vienne wrote:
Mathieu Peyréga wrote:
Bonsoir, que ce soit avec VC++ ou gcc, le code suivant ne compile pas
(ou plus exactement ne linke pas...)
Pourrais-tu être plus précis : quels sont les messages du linker ?
Compiling...
Main_test.cpp
d:projetstest_geocalclibmain_test.cpp(67) : warning C4250:
'Seq2<double>' : inherits 'Seq1<double>::setValue' via dominance
d:projetstest_geocalclibmain_test.cpp(49) : see declaration of
'setValue'
d:projetstest_geocalclibmain_test.cpp(120) : see reference to
class template instantiation 'Seq2<double>' being compiled
d:projetstest_geocalclibmain_test.cpp(67) : warning C4250:
'Seq2<double>' : inherits 'Seq1<double>::getValue' via dominance
d:projetstest_geocalclibmain_test.cpp(50) : see declaration of
'getValue'
d:projetstest_geocalclibmain_test.cpp(120) : see reference to
class template instantiation 'Seq2<double>' being compiled
La compilation ne pose donc de problèmes ni à Visual C++ 6.0 ni à gcc 3.3.1
en revanche, tout lesdeux échouent lors de l'édition des liens....
Pour la question d'un autre post du fil sur le destructeur, oui un
destructeur peut être déclaré virtuel pur, et doit avoir une
implémentation si on veux pouvoir instancier des classes dérivées
c'est du moins ce que j'ai compris en regardant la norme.
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Compiling... Main_test.cpp d:projetstest_geocalclibmain_test.cpp(67) : warning C4250: 'Seq2<double>' : inherits 'Seq1<double>::setValue' via dominance d:projetstest_geocalclibmain_test.cpp(49) : see declaration of 'setValue' d:projetstest_geocalclibmain_test.cpp(120) : see reference to class template instantiation 'Seq2<double>' being compiled d:projetstest_geocalclibmain_test.cpp(67) : warning C4250: 'Seq2<double>' : inherits 'Seq1<double>::getValue' via dominance d:projetstest_geocalclibmain_test.cpp(50) : see declaration of 'getValue' d:projetstest_geocalclibmain_test.cpp(120) : see reference to class template instantiation 'Seq2<double>' being compiled
La compilation ne pose donc de problèmes ni à Visual C++ 6.0 ni à gcc 3.3.1 en revanche, tout lesdeux échouent lors de l'édition des liens....
Pour la question d'un autre post du fil sur le destructeur, oui un destructeur peut être déclaré virtuel pur, et doit avoir une implémentation si on veux pouvoir instancier des classes dérivées c'est du moins ce que j'ai compris en regardant la norme. -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.