pointer auf statisches objekt - programm bleibt hängen?

*BHN*-Leberknecht

Hi!
Ich entwickel gerade ein kleines, plugin-basierendes tool unter linux (g++ 3.3.6).
Die Anwendung läd plugins und ruft methoden aus diesen auf, funktioniert alles wunderbar, schön polymorph usw. Nun wollte ich an eine Funktion einen Pointer auf ein Objekt in einer statischen Klasse übergeben um dieses Objekt aus dem Plugin ansprechen zu können. Hier in etwa die Struktur:

hosting app:

class myhelper
{
	public:
	void do_something()
	{
	 myapp::static_dosomething();
	}
};

class myapp
{
	static myhelper	helper_to_pass;
	static void static_dosomething()
	{
		cout << "hey static\r\n";
	}

	static void plugin_func()
	{		
		plugin_base *plugin_p; 
		//[...]  - plugin-pointer wird zugewiesen

		plugin_p->call_something(&myapp::myhelper);
	}
};

class plugin_base
{
	public:
	virtual void call_something(myhelper *arg) = 0;
};

plugin-code:

class test_plugin : public plugin_base
{
	public
	void call_something(myhelper *arg)
	{
		myhelper *helper_p = arg;
		helper_p->do_something();
	}
};

Das Programm lässt sich kompilieren, bleibt allerdings hängen (KEIN segmentation fault) wenn helper_p->do_something() gecallt wird.
Ich habe mal testweise statt einem Pointer auf ein Objekt einen Pointer auf eine statische funktion übergeben (also im beispiel wäre das ein function-pointer auf static_dosomething()) und das lief einwandfrei...was mich sehr verwirrt. Warum gehts mit funktionen aber nicht mit objekten?

Der Sinn des ganzen soll sein, dass die Plugins Zugriff auf einen bestimmte Auswahl statischer Funktionen der Anwendung haben. Da ich keine elendig lange parameter-liste mit function-pointer haben will, wollte ich das über ein objekt wrappen.

Simon2

Hi,

vorab mal ein Danke für das gute Codebeispiel.
Kannst Du Deinen Code nochmal durchsehen ?
Ich denke, es kommt auf Details an und mir ist spontan was aufgefallen, was wohl nicht stimmt...

[BHN]-Leberknecht schrieb:

...

...
class myapp
{
	static myhelper	helper_to_pass;
...
	static void plugin_func()
	{		
...
		plugin_p->call_something(&myapp::myhelper);
	}
};

Hier übergibst Du doch bestimt helper_to_pass und nicht die myapp::myhelper, oder ?

Es wäre blöd, wenn wir hier in (strukturell) anderem Code suchen als bei Dir tatsächlich läuft.

Gruß,

Simon2.

*BHN*-Leberknecht

Oh jau, stimmt natürlich, ich übergeb helper_to_pass, sorry

Ich habs inzwischen ein bischen mit gdb nachgeforscht. Das Problem ist, dass in der Funktion der lib das Symbol für do_something nicht Bekannt ist...was ja irgendwie auch logisch ist. Daher funktioniert das Ganze auch wenn ich einen function-pointer verwende (da hier ja keine symbole bekannt sein müssen, addresse und parameter-liste reichen ja), aber wenn ich ein Objekt übergebe schlägt es fehl. Wie krieg ich es jetzt hin dass die lib Zugriff auf die symbole des hosting processes kriegt? Ich lade die libs mit dlopen, da gibts ein flag RTLD_GLOBAL, dass wirkt sich aber nur auf die Symbole der geladenen lib aus (also die symbole der lib stehen anschließend global zur verfügung, können also auch von anderen libs accessed werden), aber irgendwie finde ich nichts was das gleiche mit den symbolen der hosting app macht. Ich habs mit dlopen(0,RTLD_GLOBAL) probiert, was laut den man pages eigentlich die symbole des eigenen processes laden und global zugreifbar machen sollte, aber das hat nichts gebracht.

*BHN*-Leberknecht

Hm, nachdem ich mir meine eigenen Antwort nochmal durchgelesen hab, lag die Lösung ja irgendwie auf der Hand.
Ich hab das ganze nun wie folgt gelöst:
Im hosting process habe ich ein Objekt mit der extern Speicherklasse instanziert und lade es nun aus dem Plugin mit dlopen(0,...) (womit man auf den globalen symbol-space zugreift), das Funktioniert wunderbar und macht auch die Übergabe als Parameter überflüssig die mir eh etwas unsauber erschien.
Alles roger also

Simon2

Schön, dass wir Dir helfen konnten.

Gruß,

Simon2.

P.S.: Das kenne ich von der Arbeit noch stärker - oftmals kommt man selbst auf die Lösung, wenn man das Problem jemand anderem beschreibt ... oftmals auch ohne, dass das Gegenüber verstanden hat, worum es geht (so wie hier)