une DLL doit accéder aux symboles de son application

En C++, est-il possible qu'une DLL accède à certains symboles de l'application qui l'a chargée? J'ai une application qui charge les plug-ins (dll), et ces plug-ins doivent accéder à certaines API de l'application.une DLL doit accéder aux symboles de son application

Est-il possible d'y parvenir sans créer une nouvelle DLL qui partage cette API?

Une structure de pointeurs de fonction convient-elle dans cette situation? Exemple: une fonction bool Log (char *) définie dans l'application hôte et un plug-in qui doit enregistrer certains événements.

Source

2010-12-13 Franck Freiburger

Un autre vote pour passer une interface de rappel dans la DLL du plug-in. C'est à dire. l'interface de rappel ...

class IHostApplication 
    { 
    public: 
    virtual bool Log(const wchar_t* ip_log_string) = 0; 
    };

L'interface plugin DLL

class IPlugin 
    { 
    public: 
    virtual void InitializePlugin(IHostApplication *ip_host) = 0; 
    };

L'hôte serait charger la DLL de plug-in (dynamiquement si nécessaire), et il se passe alors comme un IHostApplication * au plugin , permettant n'importe quel rappel que vous pourriez vouloir.

Source

2010-12-13 14:41:08

+1, mais est-ce un bon choix pour construire une architecture de plugin au-dessus de C++? Le plugin doit être construit avec le même compilateur C++ (si ce n'est pas la version puis au moins le constructeur). –

Vous pouvez toujours extern "C" si vous êtes si incliné - ce qui bien sûr vous limite aux interfaces de fonction de style C, mais c'est le compromis. Je suggère COM, mais je ne peux pas le faire avec un visage impassible :) –

C'est possible, mais votre choix de conception est discutable. Un EXE peut exporter des fonctions de la même manière qu'une DLL peut, de sorte que vous pouvez utiliser GetProcAddress comme vous le savez.

Cependant, pourquoi l'avez-vous conçu pour que les modules aient besoin de connaître les fonctions internes du programme hôte? Il devrait être l'inverse.

L'hôte doit exiger que les plugins implémentent un ensemble de routines (qu'ils exportent), en respectant un contrat particulier. Dans le cadre de leur interface, l'hôte peut leur transmettre des informations spécifiques à l'hôte dans un pointeur vers une structure (par exemple, des informations sur la version, des capacités) et autres, si nécessaire.

Les plugins ne doivent pas tenter d'acquérir des pointeurs de fonction vers le module hôte.

Source

2010-12-13 13:23:40

Où est le mal? Un plugin doit de toute façon adhérer à un contrat très spécifique et ne fonctionnera probablement pas si quelqu'un d'autre que l'application hôte le charge. Je ne peux pas voir beaucoup de mal si l'exécutable exporte aussi des symboles pour les plugins à appeler. –

Pointeur de fonction de rappel, liste de pointeurs de fonction de rappel ou pointeur sur l'interface de rappel - J'utiliserais l'une de ces options. Le client Dll doit implémenter l'interface de rappel et passer le pointeur vers cette interface à la DLL créée dynamiquement. Dll Dynalically créé conserve ce pointeur, et appelle ses fonctions lorsque cela est nécessaire, par exemple, pour signaler certains événements.

Source

2010-12-13 13:25:03

une DLL doit accéder aux symboles de son application

Répondre

Questions connexes