Architecture modulaire et plugin C++

Version imprimable

17/05/2012, 18h33
akrogames

Architecture modulaire et plugin C++

Bonjour à tous,

J'ai pas vraiment de problème mais plutôt des questions. J'ai une application JAVA que je souhaite redévelopper en C++ pour avoir plus de performance. Seulement mon application JAVA utilise les Services pour gérer les plugin (comme ceci: module). Bien entendu, c'est plus évolué que dans le tutoriel vu que j'utilise les Services de Java.

Mes questions sont les suivantes :
- Comment réaliser un système de plugin pour mon application C++ ?
- Je pensais utiliser des fichiers dll ou so. Est-ce une bonne piste ?
- Existe-t-il une biblio gérant tout ceci pour moi ?

D'avance merci de votre expertise.
17/05/2012, 22h37
koala01

Salut,

Si tu veux mettre un système de plug ins au point, tu n'as en effet pas beaucoup le choix : il faudra passer par des bibliothèques dynamiques (dll / so).

C++ étant un langage compilé intégralement (à l'opposé de java qui reste partiellement interprété par la JVM ;)), la dll est le seul moyen qu'il te reste pour rajouter des fonctionnalités ou pour te permettre d'en adapter à différentes situations (l'exemple classique étant l'utilisation de DirectX ou de OpenGL, par exemple ;))

Tu pourrais t'inspirer du tutoriel de laurent gomila sur la réalisation d'un moteur 3D qui, bien que datant un peu et clairement orienté vers un but précis, devrait te donner des pistes intéressantes (notamment les parties I et IV de cette série) ;)

Il est, cependant important de signaler que, dans le cadre d'une Dll, ce qui n'est pas exporté sous la forme de extern C est clairement dépendant du compilateur et de ses options de compilation:

Alors qu'une dll écrite en C est très fortement indépendante du compilateur, les dll's écrites en C++ exportent leurs objets et leur fonction en effectuant un mangling (le nom exporté est la concaténation de plusieurs éléments comme le type de retour, le nom de la classe, le nom de la fonction les paramètres, plus certains symboles qui permettent de savoir ce qui sert à quoi).

Comme il n'y a encore pour l'instant aucune standardisation en ce qui concerne le mangling, il n'est pas impossible qu'une dll compilée avec une version donnée d'un compilateur particulier (et avec des options de compilation particulières) soit incompatible avec un autre compilateur (voir une version différente du meme compilateur) ;)
17/05/2012, 22h46
JolyLoic

Oui, des DLL ou des .so sont la solution. Le problème est qu'ils sont actuellement assez complexes à utiliser. Je ne connais pas les modules java, et ne vais dont pas pouvoir mettre en avant les différences avec cette solution.

Déjà, DLL et .so possèdent des différences conceptuelles majeures :
- Une DLL doit avoir tous ses symboles résolus au moment de la compilation. Ce n'est pas le cas d'un .so qui les résous à l’exécution. La principale implication pour les plugins est qu'une DLL de plug-in ne peut pas utiliser une fonction du programme principal. On se retrouve généralement à mettre en place un triptyque : Le programme principal, une DLL de plug-in, et une DLL qui contient l'ensemble des fonctions partageables du programme principal, utilisée pas les deux premiers éléments.
- Tous les symboles sont exportés par défaut dans un .so (je crois qu'il y a moyen que ce ne soit pas le cas) alors qu'une DLL doit déclarer quel symboles seront exportés. On résout généralement ça par l'intermédiaire d'une #define qui permet à partir d'un même fichier .h de déclarer un symbole comme étant importé d'une autre DLL ou exporté de la DLL courante (ou rien pour les .so)
- Les fonctions à utiliser pour manipuler ces bibliothèques ne sont pas les même (dlopen/LoadLibrary...)
- Je suis certain d'oublier des points

Ensuite, le C++ ne défini pas ces bibliothèques dynamiques, ni même d'ABI. Ce qui fait qu'en pratique, pour que ça marche bien :
- Soit elles n'exposent que des fonctions C, ce qui est très lourd
- Soit on impose que des deux côté, tout soit compilé avec deux compilateurs ayant la même ABI et bibliothèque standard (le plus simple étant d'imposer le même compilateur, même version, mêmes options de compilation des deux côtés).

Et même là, on a parfois des surprises d’interactions entre ces bibliothèques et d'autres éléments du langage (par exemple une variable statique définie dans une bibliothèque liée statiquement à deux DLL existera en deux exemplaires dans le programme : Un exemplaire par DLL (je crois que ce n'est pas le cas avec des .so).
17/05/2012, 23h34
akrogames

Bonsoir à vous deux,

Merci de vos réponses. Aie, vu que je souhaite faire une application multi-plateforme cela va être compliqué de faire une archi-totalement modulaire car sous Windows c'est des .dll et sous nunux des .so

C'est très compliqué. Je souhaitais simplement pouvoir compiler des bouts de programmes sans tout recompiler tout mon projet. D'où la modularité. Finalement, est-ce que cela sert vraiment ?

Si j'adjoins un outil de mise à jour pour remplacer soit mes .so soit mes .dll cela ne posera pas de problème.

Merci de votre expérience en tout cas.

Bonne soirée
18/05/2012, 00h31
Matthieu Brucher

Citation:

Envoyé par JolyLoic

Déjà, DLL et .so possèdent des différences conceptuelles majeures :
- Une DLL doit avoir tous ses symboles résolus au moment de la compilation. Ce n'est pas le cas d'un .so qui les résous à l’exécution. La principale implication pour les plugins est qu'une DLL de plug-in ne peut pas utiliser une fonction du programme principal. On se retrouve généralement à mettre en place un triptyque : Le programme principal, une DLL de plug-in, et une DLL qui contient l'ensemble des fonctions partageables du programme principal, utilisée pas les deux premiers éléments.
- Tous les symboles sont exportés par défaut dans un .so (je crois qu'il y a moyen que ce ne soit pas le cas) alors qu'une DLL doit déclarer quel symboles seront exportés. On résout généralement ça par l'intermédiaire d'une #define qui permet à partir d'un même fichier .h de déclarer un symbole comme étant importé d'une autre DLL ou exporté de la DLL courante (ou rien pour les .so)
- Les fonctions à utiliser pour manipuler ces bibliothèques ne sont pas les même (dlopen/LoadLibrary...)
- Je suis certain d'oublier des points

Il y a pire pour les .so. Sous RedHat, la résolution est dynamique en fonction des bibliothèques chargées à un instant donné. Sous SUSE, tu dois avoir lié avec les bonnes bibliothèques !

Citation:

Envoyé par JolyLoic

Et même là, on a parfois des surprises d’interactions entre ces bibliothèques et d'autres éléments du langage (par exemple une variable statique définie dans une bibliothèque liée statiquement à deux DLL existera en deux exemplaires dans le programme : Un exemplaire par DLL (je crois que ce n'est pas le cas avec des .so).

Il me semble que c'est le même problème dans les deux cas. En tout cas, je ne vois pas comment ça ne serait pas le cas sous SUSE par exemple (RedHat fonctionne peut-être différemment à cause de la résolution dynamique).

J'ai fait le travail plusieurs fois sous Windows et Linux, j'ai un petit projet où tu peux récupérer des informations : https://github.com/mbrucher/TBSE/tree/master/Core
Dans mon cas, je considères que mes plugins vont enregistrer des builders dans des registres implémentés sous la forme de maps. Avec des objets statiques, j'enregistre à l'initialisation de la DLL mes builders dans la map et je peux récupérer celui que je veux par la suite. Ca signifie aussi que dans la DLL/so, je peux avoir autant de plugins que je veux et de types complètement différents.
18/05/2012, 11h28
ac_wingless

Citation:

Envoyé par akrogames

C'est très compliqué. Je souhaitais simplement pouvoir compiler des bouts de programmes sans tout recompiler tout mon projet. D'où la modularité. Finalement, est-ce que cela sert vraiment ?

Ce n'est pas compliqué, c'est simplement lourd à cause du fait qu'il faut appeler du C, en perdant donc au passage les concepts C++. Par contre, un système de plugin ne parait pas forcément impliquer des classes ou des redéfinitions de fonctions virtuelles (nous ne savons pas grand chose de votre application), donc cette pénalité n'en est pas forcément une.

Si le plugin ne propose que des services prévus à l'avance par l'application principale, c'est même très simple: importer les fonctions nécessaires, une petite encapsulation pour différencier Windows de Unix, et c'est tout.

Partager des variables est bien plus délicat, et est en pratique à proscrire totalement comme signalé ci-dessus.

JolyLoic indique aussi la manière pour que l'application principale fournisse des services. Cette DLL de service étant conçue par vous, seule son interface vue depuis les plugins doit être en C, vous pouvez garder toute la puissance de C++ dans son lien avec l'application principale, ce qui fait que cette DLL sera assez transparente de votre point de vue.

En allant en sens inverse, à savoir évaluer la puissance des DLL si on s'autorise la complexité, ne pas oublier que tout est dynamique: le nom des fonctions, le nombre et les types des arguments, etc. Tout ça avec simplement LoadLibrary et GetProc Address, sans contrainte sur le langage de développement des la DLL (Visual Basic...), je trouve que ça reste un bon système.