Exportation de DLL de classe C ++, question sur le fichier .def

Question

Je souhaite utiliser la liaison implicite dans mon projet et nmake souhaite réellement un fichier .def. Le problème est que c'est une classe et je ne sais pas quoi écrire dans la section des exportations. Quelqu'un pourrait-il me diriger dans la bonne direction?

Le message d'erreur est le suivant:

NMAKE: U1073: je ne sais pas comment faire "DLLCLASS.def"

P.S: J'essaie de créer à l'aide de Windows CE Platform Builder.

Answer 1

Vous pouvez toujours trouver le nom décoré de la fonction membre en utilisant dumpbin / symboles myclass.obj

dans mon cas

class A {
   public:
     A( int ){}
};

le vidage dumpbin affichait le symbole ?? 0A @@ QAE @ H @ Z (public: __thiscall A :: A (int))

Si vous placez ce symbole dans le fichier .def, l’éditeur de liens crée le symbole A :: A (int) dans les symboles d’exportation.

MAIS! , comme le dit @paercebal dans son commentaire: la saisie manuelle des noms décorés (mutilés) est une tâche propice aux erreurs, et malheureusement, elle n'est pas garantie d'être portable avec les versions du compilateur.

Answer 2

Si je me souviens bien, vous pouvez utiliser __ declspec (dllexport) sur la classe et VC ++ créera automatiquement des exportations pour tous les symboles liés à la classe (constructeurs / destructeur, méthodes, vtable, typeinfo, etc.).

Microsoft dispose de plus d'informations sur ce ici . .

Answer 3

J'ai trouvé le meilleur moyen de devenir une usine abstraite.

Commencez par définir une classe de base purement virtuelle. C'est une classe sans implémentation, une classe d'interface purement virtuelle.

Vous pouvez exporter cette base virtuelle " interface abstraite " classe, mais il n'y a pas de vraie raison de le faire. Lorsque l'appelant l'utilise, il l'utilise via un pointeur (PImpl ou Pointeur sur l'implémentation), de sorte que tout ce que l'appelant sait est une simple adresse mémoire. Un fichier Def, bien qu’un peu plus de travail à suivre, offre des avantages au-delà de ce que __declspec (dllexport) peut atteindre. Quels avantages, demandez-vous? Nous y arriverons, vous attendez.

Faites en sorte que votre vraie classe hérite publiquement de la base virtuelle. Créez maintenant une méthode fabrique pour construire votre objet et un destructeur appelable " release " pour effectuer un nettoyage. Attribuez à ces méthodes un nom similaire à " ConstructMyClass ". et " ReleaseMyClass ". Veuillez remplacer "" MyClass ". : -)

Ces méthodes factory / release ne doivent prendre que les types POD si elles ont besoin de paramètres (plain-old-data: integer, char, etc.). Le type de retour doit être la classe de base de votre interface abstraite virtuelle, ou plutôt un pointeur sur celle-ci.

IMyClass * CreateAnObjectOfTypeIMyClass ();

Peut-être que la raison pour laquelle nous avons besoin de la classe de base virtuelle est maintenant évidente. Comme la classe d'interface virtuelle n'a pas d'implémentation, c'est essentiellement tous les types de POD (en quelque sorte) donc le "type de données" de la classe peuvent être compris par la plupart des appelants tels que Visual Basic, C ou des compilateurs C ++ très différents.

Si vous avez suffisamment de fantaisie, vous pouvez contourner le besoin d'une " libération manuelle ". méthode (désolé, je devais le faire). Comment? Gérez vos propres ressources dans la classe grâce à des pointeurs intelligents et à une architecture de type pImpl afin que, lorsque l'objet meurt, l'objet disparaisse. Cela signifie que votre classe est, selon les mots immortels de notre saint et sauveur, facile à utiliser correctement et difficile à utiliser incorrectement " en laissant l'appelant ignorer la nécessité de nettoyer. Laissez ceux d'entre nous qui n'ont jamais oublié d'appeler " .close " jeter la première pierre.

Peut-être que cette architecture vous semble familière? Cela devrait être, en gros, une version de COM de la micro-machine. Eh bien, en quelque sorte, au moins le concept d’interface, de construction en usine et de libération.

En fin de compte, vous avez exporté l'interface pour votre classe, les méthodes Créer et Détruire , et les appelants peuvent désormais appeler votre PleaseConstructMyClass. fonction d'usine pour que votre DLL renvoie un objet entièrement construit, entièrement implémenté et entièrement cuit sous l'apparence de son interface. Ils peuvent appeler toutes les méthodes publiques de votre classe (du moins celles de votre interface virtuelle abstraite) et faire tout ce qui est amusant.

Une fois qu'ils ont terminé avec l'objet renvoyé par la fonction factory, ils peuvent appeler un " ReleaseMyClass ". pour demander à votre DLL de nettoyer les ressources de l’objet, ou vous pouvez les aider en faisant en sorte que votre classe se nettoie elle-même, ce qui rend le paramètre " ReleaseMyClass ". méthode redondante et inutile.

Si quelqu'un est intéressé par les gains spécifiques & amp; Des compromis pour l’utilisation du fichier Def et de l’interface (en plus de mon dicton aveugle), connectez-vous et nous pouvons aller plus loin.

Tu n'aimes pas ce genre de choses?

Answer 4

La solution est la suivante:

• puisqu’une classe est exportée, vous devez également ajouter les méthodes exportées dans le fichier .def

• Je n'ai pas trouvé comment exporter un constructeur, je me suis donc servi d'une méthode de fabrique (statique), qui renverrait de nouvelles instances d'un objet

• les autres fonctions seront exportées en ajoutant une déclaration d'exportation normale dans le fichier .def

J'espère que quelqu'un bénéficiera de cette information.