Discussion :

[darkman19320]

Bonjour tout le monde,

Je cherche � trouver un moyen pour extraire l'ensemble des m�thodes pr�sentes dans une biblioth�que dynamique (C++) (.so ou .dll). Pour le moment, j'utilise des outils externes comme nm sous linux ou Dependency Walker pour les lister.

J'aimerais pouvoir charger ces m�thodes de mani�re dynamique directement depuis un programme. Est-ce qu'il y a des biblioth�ques open source qui permettent �a?

Je pensais � une interface de ce genre:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
//allMethods comprend les différentes méthodes avec leurs arguments associés
std::vector<Methods> allMethods = listMethods("myBiblio.so"); //listMethods("myBiblio.dll");
//allMethods[0].functionType() retournerait un std::function avec le bon paramètre de retour ainsi que les bons arguments
allMethods[0].functionType() func1 = loadMethod<allMethods[0].functionType()>(allMethods[0].name());

Il faudra bien s�r que je trouve une m�thode pour convertir un string en type (int, double, etc....) voir en classe. (c'est le principe de r�flexion non?)

Merci pour tout.

[bacelar]

Ce que je vais affirmer ici n'est valable que pour les dll, je ne connais absolument pas les .so.

Dans une dll "classique", il n'y aucune information autre que les noms d�cor�s avec un indice dans une table d'offset dans le code.
https://msdn.microsoft.com/en-us/magazine/cc301808.aspx
Pour avoir la liste des fonctions export�es, il faut donc juste lire la structure "IMAGE_EXPORT_DIRECTORY" dans la partie en-t�te d'un fichier au format PE.

Si vous voulez acc�der aux autres informations (nombres de param�tres, types de param�tres, type de retour), il faut que vous ayez acc�s aux informations des debuggings, que chaque chaine de compilation traite et stocke de mani�re diff�rente (fichier pdb, section de donn�es en CodeView7).
Les dll "imagehlp.dll" et "dbghelp.dll" permettent de lire ces informations sans tout interpr�ter � la main (en plus, c'est fonction du compilateur).


Dependency Walker utilise le mangling de VS pour r�cup�rer la signature des m�thodes C++, �a ne marche donc qu'avec du code �crit en C++ compil� avec VS.

[darkman19320]

Merci pour cette r�ponse d�taill�e.

Je voulais � la base ne fournir qu'une biblioth�que dynamique � mon application qui "interpr�terait" automatiquement l'ensemble des m�thodes fournies par le plugin.

Au vu de la complexit� et surtout de la contrainte de devoir compiler les biblioth�ques (plugins) en debug pour avoir acc�s aux param�tres, je vais plut�t me tourner vers une m�thode qui listera les param�tres ainsi que les noms des fonctions associ�es (enfin, quelque chose dans le genre).

[Bousk]

Hello,

peut-�tre que tu peux prendre le probl�me � l'envers et utiliser le scripting.
Tu fournis une API en script (Python, LUA, ..) depuis ton appli, un moyen de faire comprendre � l'application que tel fichier c'est un script de plugin et qu'il doit appeler. Dans le script, l'utilisateur peut manoeuvrer l'appli avec ton API.

[darkman19320]

Effectivement, je pourrais faire �a mais le but �tait plus d'�viter d'avoir un autre fichier en plus de la biblioth�que dynamique. En plus, je suis dans un domaine (m�dical) o� l'on ne souhaite surtout pas que l'utilisateur puisse faire des "bidouilles" et risque de cr�er un comportement inattendu.

[ternel]

Il suffit de ne pas lui donner acc�s � tout.
Avec du scripting, tu ne donnes acc�s qu'� une partie des fonctions/variables.

Ca peut �tre tr�s contr�l�.