2010-06-15 4 views
0

virtuelle Chacune de ces classes sont en modules séparés dll:symbole externe non résolu sur la fonction

class Base 
{ 
public: 
    virtual void foo(); 
    void bar(); 
}; 


class Derived : public Base 
{ 
public: 
    // override Base::foo() 
    void foo(); 
}; 

En Other.cpp:

#include "Derived.h" 

Le module qui contient des liens dérivés avec Base.lib (non montré sont les directives export/import). Le module qui contient des liens Other.cpp avec Derived.lib, mais pas Base.lib. Jusqu'à présent, tout fonctionne bien.

Cependant, si je change la barre de base() pour être virtuel et ne fait pas de changement à Derived, puis l'éditeur de liens se plaint lors de la liaison Other.dll:

Other.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Base::bar()" ... 

Les seules solutions que j'ai trouvé est de surcharger Base :: bar() dans Derived ou d'avoir aussi un lien vers Other.dll avec Base.lib. Les deux solutions ne sont pas souhaitées car elles ajoutent des exigences client lorsque le serveur change.

Des idées sur un meilleur moyen d'accéder/définir les méthodes virtuelles de classe de base dans ce scénario?

Répondre

2

Qu'est-ce qui se passe est que virtual Base::bar doit être dans le vtable d'un dérivé, car il n'y a pas Derived::bar.

Je ne comprends pas votre commentaire sur "les exigences du client lorsque le serveur change". Je ne vois pas comment les cartes de base/dérivées au client/serveur. Ils sont deux dimensions indépendantes pour moi.

Questions connexes