Salut
Je bosse sous Solaris 8 en C++.
 
J'aimerais savoir s'il est possible d'ouvrir explicitement un .so avec dlopen et d'y appeler une méthode sur un objet. Le probleme, c'est que dlsym renvoie un void * , une fonction "C, ce qui n'est pas pareil qu'une méthode avec un this implicite.
Donc en C, quand je recupere l'adresse avec dlsym je fais (*f)().
Mais avec mon objet je fais quoi ? Un truc du genre (*f)(this,arguments) ? Et de toute façon je ne sais même pas comment s'appelle le symbole vu qu'il est décoré à la C++.
 
Existe t il un truc que je ne connais pas ?
 
Merci d'avance

construis ton objet dans ton.so, puis exporte une fonction qui crée un de ces objets, et qui une autre qui le détruit.
Passe par une interface pour isoler l'implémentation dans le .so
et l'utilisation dans ton programme.

tu sais te servir d'un pointeur de fonction membre ?

passe par une interface tu veux dire d'utiliser une classe avec des methodes virtuelles pures, de l'implémenter dans le .so, et de faire 2 fonctions extern "C" dans le .so qui retournent un pointeur sur l'interface c ca ?
 
j'y avais pensé mais je trouvais que c'etait moyen. Parce que quand on linke en automatique avec un .so, cad on le mat dans la ligne de commande de link, le linker se demerde bien pour aller appeler les méthodes dans le .so
je me disais que peut etre il y avait un moyen de faire pareil, mais a la main plutot que de laisser le compilo générer lui meme les dlopen et compagnie qui vont bien

 
pointeur de fonction membre ok admettons
mais pour le constructeur et le destructeur qui sont appelés implicitement, tu fais comment ?
et pour le nom du symbole qu'il faut passer à dlsym tu le connais comment ?

ché pas, mais je le sens impossible là

 
bin moi aussi je pense que c pas possible, du moins proprement
il faudrait un truc qui te fait une sorte de représentation locale de la classe et qui va lui meme chercher les symboles.
Mais bon si ca existait quelqu'un le saurait surement  
 
tant pis je ferai autrement...

bin ma méthode elle marche bien
représentation locale = interface (oui j'entends par la une classe et des méthodes virtuelles pures, et deux fonctions C)
 
au fait, petite question sur le sujet : le programme et le .so partagent les mêmes allocateurs ? (le même tas, etc ...)

http://www.isotton.com/howtos/C++- [...] ingclasses
http://www.linuxjournal.com/article.php?sid=3687
 
la methode est simple, passé par une fonction C (dans un exterc C) qui renvoi un pointeur sur l'objet, je trouve pas ça tres propre, mais cest a prioris la seule solution, et ca marche bien. Il y avait un autre topic sur le sujet, et cest la seule solution qui ait été trouvé

bin c ce que je viens de dire lol

il me semblait que ce pb n'existe que sous windows, selon la CRT qui est utilisée. Le pb se pose aussi sous unix?

sinon, une autre petite question : les exceptions remontent jusqu'au programme qui appelle une fonction de la dll ? ou ca plante s'il n'y a pas de catch dans la dll ?

tu peux lever une exception dans un module et l'attraper dans un autre. Donc la réponse est: oui.
Sous linux/unix, il faut bien faire attention de faire l'édition de lien et la création de la bibliothèque avec g++ et non pas ld, sans quoi l'exception risque bien de ne pas être attrapée. C'est sans doute une question d'option à passer à ld, mais je n'ai jamais su de laquelle il s'agit!