Discussion :

[akrogames]

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.

[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)

[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).

[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

[Matthieu Brucher]

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 !

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.

[ac_wingless]

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.