Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Plugins en C++
Bonjour,
Je voudrais avoir des renseignements dans ce domaine, je suis tout nouveau...
Tout d'abord, concrètement, à quoi ça revient un plugin? Une DLL qu'on rajoute? Un code que notre programme interprète?
Comment faire un plugin multi-OS?
Je serai ravi de profiter de l'expérience de certains.
Si éventuellement vous avez de la bonne documentation, ou même un exemple facile à comprendre pour un débutant dans ce domaine comme moi, je suis preneur
Merci d'avance.
Voici un article que je n'ai pas encore lu, mais qui m'a l'air plutôt bien fourni : http://www.ddj.com/cpp/204202899
Je sens que tu vas bien t'amuser
Bonjour,
Je ne suis pas expert sur le sujet, mais histoire de participer, je peux rappeler les bases.
Le principe du plug-in c'est de pouvoir rajouter des fonctionnalités sans modifier le programme principal. Donc effectivement, un plug-in sera une dll.
En ce qui concerne la portabilité, c'est toujours le même problème avec les langages compilés: qu'il y ait plug-in ou non, il faut recompilé ton appli (et les plugins) sur chaque os cible.
Le principe de base de gestion de plug-in est le suivant:
ton appli propose une interface que le plug-in va implémenter. Souvent, ce n'est qu'une seule fonction. La plupart du temps, en c++, on utilise l'héritage: ton appli fourni l'en tête d'une classe qui va être dérivée dans le plug-in.
Au niveau de la gestion des fichiers, le plus simple est de déterminer à l'avance un dossier dans lequel vont être stockées les dlls, de scanner ces fichiers et de charger tous ceux qui implémentent l'interface sus-dite.
Je n'en sais pas plus.
Les systèmes de DLLs et de so (et sûrement ceux de Mac) ne s'intègrent pas vraiment bien dans C++ et sont tous assez différents.
Il vaut mieux utiliser une bibliothèque qui abstrait ça ; il y avait à un moment discussion d'une bibliothèque Boost.Extension.
Mieux que ça : il en a même été question dans C++0x. Voir ici, à "Modules in C++" : http://www.open-std.org/jtc1/sc22/wg...008/n2705.html ou directement le pdf ici : http://www.open-std.org/jtc1/sc22/wg...2007/n2316.pdfEnvoyé par loufoque
Malheureusement il faudra attendre, comme ils le disent si bien : These topics are deemed too important to wait for another standard after C++0x before being published, but too experimental to be finalised in time for the next Standard. Therefore, these features will be delivered by a technical report at the earliest opportunity.
Très bon sujet.
J'ai lu quelques docs, et ce n'est pas ci compliqué que ça.
Lorsque c'est pour rajouter des fonctionnalités, ça ne pose pas de problème, par contre, est-ce que ça se fait un plugin pour modifier le coeur ?
Voici mon soucis :
Le coeur de mon apply possède des véhicules standards, avec une vue pour les afficher, les éditer etc...
Est-ce que ça se fait de créer un plugin pour étendre ces véhicules standards (pour ajouter une propriété, modifier un comportement), et modifier la vue standard pour ajouter/modifier l'interface graphique afin, par exemple, de rajouter un champ d'édition d'une nouvelle propriété que n'avait pas le véhicule standard ?
Car si je ne fonctionne que par interface, beaucoup de données "standards" devront être redéfinies dans chaque plugins, il faudra également refaire la construction des parties standards de l'IHM à chaque fois...
Merci
En général, la technique des plugins se décompose en plusieurs parties:
-> L'exposition d'une ou plusieurs interfaces permettant d'agir sur l'applicatif de base (ajout de données, enrichissement de l'IHM, ...) --> La responsabilité en incombe à l'application,
-> Un mécanisme d'intégration et d'invocation du plugin,
-> L'écriture du plugin qui rajoute ces nouveaux services.
Ensuite, un plugin peut être vue comme une DLL et ses équivalents dans les autres OS -> recompilation dans les OS cible à chaque fois.
Mais ça peut aussi être un exécutable en soit avec des mécanismes d'échange. -> idem, recompilation OS/Plugin pour chaque OS.
Une autre solution est de passer par du scripting (Python par expl) -> Là, seule l'appli a besoin d'être recompilée.
Salut.
En C++, Qt fournie une lib pour simplifier cela :
http://qt.developpez.com/doc/latest/plugins-howto.html
Aprés peut être que par plug-in tu pensais scripter une appli?
Salut,
Il y a également libltdl.
MAT.
Salut,
je viens de finir une application qui gère justement des plugins, si vous être intéressé je peux mettre les sources de l'exemple que j'ai fait en ligne.
Sinon, pour expliquer rapidement comment je fonctionne:
mon appli principale a une classe gestionnaire, qui va gérer mes plugin (chargement, déchargement, etc), et utilise les MFC. Pour connaitre mes plugin, j'ai un fichier xml auprès duquel vont s'incrire les nouveaux plugin ajouté, et qui est lut au lancement de l'appli pour charger les dll dynamiquement.
Ensuite, pour mes dll, elles contiennent des boite de dialogue qui sont affichées par le gestionnaire, et servent à communiquer avec des applications distantes (via socket) que j'ai déjà écritent.
Bon, mon utilisation des plugins est assez spécifique, mais le systeme est généraliste et peut etre adapté aux besoins de chacun.
C'est bizarre, la liste des bibliothèques fournies par Boost ne mentionne pas celle là. Pourtant, on trouve bien la page pas d'autre moyens.
Je me demande si elle n'a pas été dégagée de Boost.
Salut,
merci pour toutes ces réponses
J'étais tombé sur le document de C++0X, dommage que ça n'existe déjà pas.
J'ai regardé l'exemple de Qt, il y a toute une liste de classes de base, à dériver, pour faire un plug-in.
C'est là que je ne comprends pas trop. Lorsqu'on importe un plugin, on utilise seulement une DLL mais on ne regarde pas dans les fichiers .h, non? Parce que le principe d'un plugin, c'est d'être rajouté sans modifier l'exécutable...
Pour pouvoir utiliser le plugin, il faut donc déclarer une classe, ou déclarer une fonction, qui sera définie dans le plugin? Je n'arrive pas à comprendre comment on peut faire ce genre de chose, le compilateur ne connaît pas alors le fichier .dll :s
C'est à dire qu'il faut que je me renseigne pour trouver comment utiliser des DLL dynamiquement, sans linkage préalable (si j'ai bien compris...)
wogkiller, ton source m'intéresse, j'espère que ça pourra m'aider à comprendre comment le plugin est utilisé dans un programme.
C'est quand même hallucinant la variété des choses que l'on peut faire avec un plugin: un snake sous codeblocks, des téléchargeurs de vidéo sous mozilla...
Voilà voilà
En gros comment ca marche :
tu charge en mémoire du code (dll) puis retrouve des fonctions (sous forme de pointeur) pour l'exploiter.
Les lib que l'on t'as donné font cela.
Après y as aussi les scriptes qui permette de contrôler ton appli. Par exemple la gestion de l'IA dans certain jeux sont fait au travers de LUA.
Après ca dépend ce que tu veut faire.
les dll ajoute du code à ton appli
les scripte utilisent ce qu'il y as dans ton appli
Non. Ça n'a jamais été intégré dans Boost pour le moment.Je me demande si elle n'a pas été dégagée de Boost.
Ce n'est qu'une proposition de bibliothèque, il faut la reviewer etc. pour qu'elle soit intégrée.
J'imagine que ça ne va pas tarder
Et il y a une page sur le site de Boost qui répertorie les "propositions" ?
Avec le statut desdites bibliothèques dans la communauté Boost ?
Je viens de fouiller, mais je n'ai rien trouvé.
Non, pour ça il faut suivre la Mailing List.
http://www.boost.org/community/review_schedule.html
Ce n'est même pas dans la review queue, tout simplement parce que la bibliothèque n'est pas finie et nécessite d'être repensée sur certains aspects.
C'est là ou la grande force de la virtualité arrive....
Bon... Il y a 2 modes de fonctionnement pour les plug-ins....
Les plug-ins "appartement" (le plug-in ne connait pas l'appli qui l'utilise, et s'en fiche royalement). C'est le mode de la plupart des plugins photoshop par exemple (et ce qui permet au passage, d'utiliser ces mêmes plugins photoshop dans 99% des logiciels d'imagerie).
Dans ce mode, les plug-ins peuvent avoir des connaissance "data", sans plus (définition de types, structures, etc...).
Et puis il y a le mode "interactif"... Le plug-in connait l'application. En général celà se fait par DLL intermédiaire... et il peut connaitre les types de cette DLL...
EXE dépend de MainDLL
PlugIn1DLL dépend de MainDLL
PlugIn2DLL dépend de MainDLL
Au final, MainDLL ne sera bien chargé qu'une seul et unique fois....
Sinon pour répondre à un autre post... il vaut 100x mieux regarder un répertoire "plugins" de l'appli, et charger tout ce qu'il y a dedans, plutot que de s'amuser à rajouter dans un fichier xml (comme finalement, le fait regsvr32)
Mais bon....
Mais regarde un peu ce qu'a fait Laurent :
http://loulou.developpez.com/tutorie.../partie1/#L3.2
Il a fait un moteur graphique utilisant tant OpenGL que DirectX9. Dans le coeur, il propose des classes abstraites qu'étendront les classes concrètes situés dans les DLL (car on peut vouloir à terme gérer DirectX10)
Ensuite le moteur manipule du IRenderer, du ILight etc... mais en fait ce sont des CDx9Renderer, CDx9Light ou COglRenderer, COglLight selon la librairie chargée au début de l'application.
Le coeur connait les librairies utilisables, et les noms des fichiers DLL sont en dur dans le code, mais il est tout à fait possible de les retrouver en scannant un répertoire, ou en les référençant dans un XML par exemple, et de laisser l'utilisateur choisir. Je pense que je vais m'appuyer là dessus.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager