Qu'est-ce qui est sûr pour un système de plug-ins C++ ?

Question

Les systèmes de plug-ins en C++ sont difficiles car l'ABI n'est pas correctement défini et chaque compilateur (ou version de celui-ci) suit ses propres règles.Cependant, COM sous Windows montre qu'il est possible de créer un système de plug-ins minimal permettant aux programmeurs utilisant différents compilateurs de créer des plug-ins pour une application hôte à l'aide d'une interface simple.

Soyons pratiques et laissons de côté le standard C++, qui n'est pas très utile à cet égard.Si je souhaite écrire une application pour Windows et Mac (et éventuellement Linux) qui prend en charge les plug-ins C++, et si je souhaite offrir aux auteurs de plug-ins un choix raisonnablement large de compilateurs (disons des versions de Visual C++ datant de moins de 2 ans) , GCC ou le compilateur C++ d'Intel), sur quelles fonctionnalités du C++ puis-je compter ?

Bien sûr, je suppose que les plug-ins seraient écrits pour une plateforme spécifique.

De mémoire, voici quelques fonctionnalités C++ auxquelles je peux penser, avec ce que je pense être la réponse :

• Disposition vtable, pour utiliser des objets via des classes abstraites ?(Oui)
• types intégrés, pointeurs ?(Oui)
• des structures, des syndicats ?(Oui)
• des exceptions?(Non)
• fonctions externes "C" ?(Oui)
• stdcall fonctions "C" non externes avec types de paramètres intégrés ?(Oui)
• Fonctions "C" non externes non stdcall avec types de paramètres définis par l'utilisateur ?(Non)

J'apprécierais toute expérience que vous avez dans ce domaine et que vous pourriez partager.Si vous connaissez une application moyennement performante dotée d'un système de plug-in C++, c'est cool aussi.

Carl

Answer 1

Le Journal du Dr Dobb contient un article Construire votre propre framework de plugins :Partie 1 ce qui est une assez bonne lecture sur le sujet.C'est le début d'une série d'articles qui couvrent l'architecture, le développement et le déploiement d'un framework de plugins multiplateforme C/C++.

Answer 2

Vous pouvez également envisager de remplacer l’interface de plugin conventionnelle par une interface de script.Il existe de très bonnes liaisons pour plusieurs langages de script en C/C++ qui ont déjà résolu votre problème.Ce n’est peut-être pas une mauvaise idée de s’appuyer sur eux.Par exemple, jetez un oeil à Boost.Python.

Answer 3

Qt a un très bon système pour les plugins que j'ai utilisé dans le passé.Il utilise le système de méta-objets de Qt pour surmonter de nombreux problèmes généralement rencontrés lors du développement de plugins C++.

Un exemple est comment Q_DECLARE_INTERFACE fonctionne, pour vous empêcher d'utiliser un plugin incompatible.Un autre est le clé de construction, pour vous assurer de charger le plugin approprié pour votre architecture, votre système d'exploitation et votre compilateur.Si vous n'utilisez pas le système de plugins de Qt, ce sont des choses dont vous devrez vous soucier et inventer des solutions par vous-même.Ce n'est pas nécessairement sorcier, et je ne dis pas que vous échoueriez, mais les gars de Trolltech sont plutôt intelligents et ont passé un moment à y réfléchir, et je préfère utiliser ce qu'ils ont créé plutôt que de réinventer la roue moi-même. .

Un autre exemple est que RTTI ne fonctionne généralement pas au-delà des limites des DLL, mais lors de l'utilisation de Qt, des choses comme qobject_cast qui s'appuient sur le système de méta-objets fonctionnent au-delà des limites des DLL.

Answer 4

Je pense que vous pouvez créer en toute sécurité un système de plugins basé sur :

• Conditionnement des fonctionnalités du plugin dans une bibliothèque (.dll, .so, etc.)
• Exiger que le plugin expose les principales exportations en langage C.
• Exiger que le plugin implémente (et renvoie un pointeur/référence vers) une interface C++ abstraite.

Probablement le système de plugins C++ le plus performant :bon vieux Adobe Photoshop.Et sinon, un des formats de synthétiseur virtuel comme VSTi etc.

Answer 5

Le livre C++ imparfait par Matthew Wilson a une bonne information à ce sujet.

Le conseil dans le semble être :tant que vous utilisez le même compilateur (ou équivalent), vous pouvez utiliser C++, sinon il est préférable d'utiliser C comme interface au-dessus de votre code C++.

Answer 6

AS a une architecture de plug-in multiplateforme.

Vérifier:

1. DLL ACE
2. Gestionnaire de DLL ACE

Je suggérerais de consulter le livre
Le guide du programmeur ACE

Answer 7

Firefox fonctionne sur XPCOM (http://www.mozilla.org/projects/xpcom/).Il est inspiré de Microsoft COM mais est multiplateforme.

Answer 8

J'ai mon propre moteur de jeu doté d'un système de plug-in C++.

J'ai du code dans les fichiers d'en-tête afin qu'il soit placé dans l'unité de compilation du plugin.

Les fonctions plus volumineuses qui résident dans le moteur principal sont appelées via une fonction C exportée (le plugin appelle MyObject_somefunction(MyObject *obj) qui dans le moteur appelle simplement obj->somefunction()).Si appeler une fonction C est moche à votre goût, alors avec quelques astuces d'en-tête, lorsque l'en-tête est inclus dans le plugin, faites en sorte que la fonction membre # soit définie pour appeler la fonction C :

#if defined(IN_THE_PLUGIN)
void MyObject::somefunction() { MyObject_somefunction(this); }
#endif

Les fonctions virtuelles doivent être pures ou le code réside dans le fichier d'en-tête.Si je n'hérite pas d'une classe et que j'en instancie simplement une, le code de fonction virtuelle peut vivre dans le moteur, mais la classe doit alors exporter certaines fonctions C pour créer et détruire l'objet appelé depuis le plugin.

Fondamentalement, les astuces que j'ai utilisées, dans le but de conserver une totale indépendance de la plateforme, se résument à des exportations C et à des astuces sur les fichiers d'en-tête.