La classe de base pure doit être exportée de DLL?

Question

J'ai deux DLL a.dll et b.dll et dans chacun j'ai une classe AClass et BClass.
Je voudrais que AClass et BClass héritent et implémentent la même interface AbsBase qui est une pure classe abstraite.
Dans chaque classe, j'ai défini les #defines pour __declspec (dllimport) et __declspect (dllexport). Quand je suis en train de compiler je reçois ceci:

avertissement C4275: classe non dll interface 'AClass' utilisé comme base pour la classe dll-interface 'AbsBase'

qui veut essentiellement déclarer AbsBase comme __declspec (dllexport)
Mais si le compilateur le voulait, je devrais déclarer AbsBase pour être exporté depuis a.dll et b.dll.

Pourquoi l'interface d'une classe doit-elle être exportée?
Y a-t-il un moyen de contourner le problème? dois-je vraiment exporter AbsBase des deux DLL? N'y a-t-il pas quelque chose qui ne va pas? (Je aurais besoin de définir une nouvelle macro XXX_EXPORT ..)

Answer 1

Il semble que ce soit un avertissement du compilateur et non une erreur, donc cela devrait fonctionner. Le compilateur vous fait juste savoir que vous faites quelque chose qui vous facilite la tâche. Il devrait être parfaitement acceptable de le faire tant que les deux DLL et le programme principal sont d'accord sur la définition de la classe de base.

Vous devriez être en mesure d'utiliser un pragma pour supress l'avertissement:

http://forums.devx.com/archive/index.php/t-84785.html

Answer 2

J'ai un conseil:

class Base { 
    public: 
    virtual void f() = 0; 
    virtual void g() = 0; 
    virtual ~Base(); 
}; 

class A: public Base { 
    public: 
    virtual void f(); 
    virtual void g(); 
}; 

class B: public Base { 
    public: 
    virtual void g(); // REVERSE ORDER 
    virtual void f(); 
}; 

L'ordre de f et g dans le tableau de méthode virtuelle est spécifiée dans la classe de base et cette information est très nécessaire.

Answer 3

C'est quelque chose à s'inquiéter. Le compilateur a détecté que le code de la classe de base peut s'exécuter. Ce ne sera pas une pure méthode virtuelle, elle sait comment les filtrer. Peut-être un constructeur ou un destructeur? Le mode de défaillance est que la disposition de la mémoire de l'objet de classe peut ne pas être la même dans le code client par rapport à la DLL. Le chaos d'exécution de cette cause est très difficile à diagnostiquer. Cela ne pose aucun problème si vous garantissez que le client et la DLL sont compilés avec exactement les mêmes paramètres de compilation et de liaison, en utilisant exactement les mêmes versions du CRT et de ces outils. Vous pouvez rendre la classe de base garantie abstraite en utilisant le mot clé __interface non standard au lieu de class.