Zugriff auf Methoden abgeleiteter Klassen die allerdings nicht in der Basisklasse definiert sind mit Basisklassenzeiger

otze

ssm schrieb:

otze schrieb:

das system is einfach:
du übergibst registerplugin einen nach XComBase* konvertierbaren pointer.
innerhalb der funktion wird dann versucht die richtige version von accept aufzurufen,accept macht dann irgendetwas mit dem pointer,je nachdem wie die implementierung ist

@ssm jo das is richtig, ich wollte ja auch nie nen dynamic cast verwenden :p

genau, das hab ich vergessen.
es gibt noch bessere Lösung, von Andrey Aleksandrevsku.

jo, sein buch lliegt grad neben mir, hats zb mit ner typliste geschafft, was ein teufelskerl

ssm

fluxy schrieb:

von wem?!

von Andrei Alexandrescu, http://www.moderncppdesign.com/

fluxy schrieb:

wie wären denn die besseren lösungen?

http://sourceforge.net/projects/loki-lib/
die sind aber sehr kompleciert

fluxy schrieb:

ach und deutsch muss net sein... ich bin auch der englischen Sprache mächtig.

ich kann ohne Probleme English, Deutsch, Russisch verstehen, aber schreiben ...
meine Muttersprache ist ukrainish

ssm

otze schrieb:

jo, sein buch lliegt grad neben mir, hats zb mit ner typliste geschafft, was ein teufelskerl

ja, genau, es gibt keine andere Benennung

fluxy

hmmm,

also wie viel besser sind die denn als deine Lösung. Also die Lösung mit dieser Factory habe ich noch nicht so ganz verstanden. Deshalb eine Frage:

Wenn ich die Factory benutzte dann brauche ich keinen Cast mehr auf meine anderen Klassen, also meine Anwendung braucht die anderen Klassen auf keinste weise mehr zu kennen?!?

Bitte um ne klare Antwort.

otze

das interface muss immernoch gekannt werden,das is auch kein unterschied zu dynamic_cast oder dem was ich vorgeschlagen hab

und die andre lösung von Andrei Alexandrescu ist vom niveau her für uns hier unerreichbar.

ssm

otze schrieb:

das interface muss immernoch gekannt werden,das is auch kein unterschied zu dynamic_cast oder dem was ich vorgeschlagen hab

Geschwindigkeit? RTTI?

otze schrieb:

und die andre lösung von Andrei Alexandrescu ist vom niveau her für uns hier unerreichbar.

man braucht IMHO einfach viel Zeit, um sie zu verstehen. Aber die Idee ist SUPER

fluxy

das interface oder die klasse? was ist wenn ich nur ein interface habe und habe eine Methode in der abgeleiteten Klasse die das interface nicht hat?

ssm

fluxy schrieb:

hmmm,

also wie viel besser sind die denn als deine Lösung. Also die Lösung mit dieser Factory habe ich noch nicht so ganz verstanden. Deshalb eine Frage:

Wenn ich die Factory benutzte dann brauche ich keinen Cast mehr auf meine anderen Klassen, also meine Anwendung braucht die anderen Klassen auf keinste weise mehr zu kennen?!?

Bitte um ne klare Antwort.

wie otze schrieb, muss interface gekannt werden. Wenn ich richtig verstand, du hast doch diese Information.

otze

Geschwindigkeit? RTTI?

normalerweise richtig, in dem kontext aber nicht relevant

ansonsten hat ssm uneingeschränkt recht

@fluxy wenn die abgeleitete klasse eine methode hat, die kein dir bekanntes interface ansprechen kann, dann wirst du wohl auf diese methode verzichten müssen.

in einem plugin system, welches sich aus verschiedenen dlls läd könntest du eh nichts mit der "neuen" methode anfangen, da du sie nicht kennen KANNST.

ssm

fluxy schrieb:

das interface oder die klasse? was ist wenn ich nur ein interface habe und habe eine Methode in der abgeleiteten Klasse die das interface nicht hat?

du sollst diese Methode im interface einfügen, oder du kannst ein interface in daine Klasse einfügen, die Client nich siet:

[cpp]struct IHidden;
struct IPluggin;

struct IVisitor
{
virtual void accept(IHidden *hidden) = 0;
virtual void accept(IPluggin *pluggin) = 0;
};

struct IPluggin
{
virtual void init() = 0;
virtual void abort() = 0;
virtual void stop() = 0;
virtual accept(IVisitor *visitor);
};

struct IHidden
{
virtual void magic() = 0;
};

template<typename>
class PlugginImpl
{
};

class MyPluggin1 : public PlugginImpl<MyPluggin1>, IHidden
{
virtual void magic()
{
std::cout << "make magic\n";
}

virtual apply(IVisitor *visitor)
{
visitor->accept(static_cast<IHidden>(this));
}
};[/cpp]

fluxy

Welchen Ansatz verfolgt denn dieser Typ da?

ssm

fluxy schrieb:

Welchen Ansatz verfolgt denn dieser Typ da?

Er dient als der Kleber, und läßt dir zu, die verborgenen Möglichkeiten deine pluggins zu benutzen

fluxy

nein ich meinte diesen typ von dem du geredet hattest.... von der Möglichkeit die zu kompliziert sei...

Ich will es mal so ausdrücken: Wenn ich mich schon bemühen muss, eine Lösung zu verstehen, dann nehme ich doch die beste.... Vielleicht kannst du dich ja auch mal unter sebastianschabbach@gmx.de melden das geht vielleicht einfacher.

otze

kauf dir modernes c++ design von andrei alexandrescou. da steht alles drin, was du wissen musst, denn für die erklärung müsste man weit ausholen

fluxy

okay ich habe es jetzt geändert. Meine Funktion die in der Dll die instanz erstellt erwartet jetzt einen XComGuiBase (natürlich nur in der gui dll).

das ganze sieht jetzt so aus :

unsigned long XComManager::registerPlugin (unsigned long plgID, XComGuiBase* ptr_base, XGuiMessageSystem* ptr_message)
{
	HMODULE hDll = (HMODULE) NULL;
	char* dllname = new char [100];
	static int counter = 0;

	// GUI - Plugin laden
	if (plgID == PLG_GUI)
	{

		*mglog << "Plugin erkannt auf PLG_GUI" << endl;
#ifdef WIN32
		strcpy ((char*)dllname, (char*)"dll");
		strcat ((char*)dllname, (char*)"\\XWin32.dll");
		*mglog << "Betriebsystem erkannt auf >>WINDOWS<<" << endl;

		if (!(hDll = LoadLibraryEx (dllname, NULL, 0)))
		{
			*mglog << "Error binding Dll to application's address space" << endl;
		}

		/* Zeiger auf die richtige Klasse initialisieren und dann im Pluginvektor
		   abspeichern, damit die Anwendung darauf zugreifen kann
	   */
		GUI_PLG gplg = NULL;
		gplg = (GUI_PLG) GetProcAddress (hDll, "XExport");
		gplg (hDll, &ptr_base, ptr_message);

		plgStack.insert(make_pair (counter, ptr_base));
		*mglog << "Neues Element in map eingefügt mit ID " << counter << endl;
		counter++;

#else
		//Lade Linuxpluigin
#endif
	}

	// Render - Plugin laden
	else if (plgID == PLG_RENDER)
	{
	}

	return 0;
}

Leider schmiert das Programm beim Einfügen in die Map ab. Kann mir jemand sagen warum ?!

otze

wieso castest du hier?

strcpy ((char*)dllname, (char*)"dll"); 
strcat ((char*)dllname, (char*)"\\XWin32.dll");

das sind doch schon beides char*(und wieso benutzt du die c style casts?)

fluxy

Emmm hat keinen besonderen Grund... Es ist weil wir in der Firma reines C programmieren und ich nicht immer hinundherswitschen kann. Muss mich irgendwie auch den gegebenheiten anpassen.

otze

aber da sind absolut keine casts notwendig ?!
auch der cast is sinnfrei:

HMODULE hDll = (HMODULE) NULL;

btw:
stürzt das programm nich vielleicht schon hier ab?

GUI_PLG gplg = NULL; 
gplg = (GUI_PLG) GetProcAddress (hDll, "XExport"); 
gplg (hDll, &ptr_base, ptr_message);

ist gplg(was heisst das?) auch sicher nicht null?

fluxy

nein dasd programm stürzt da noch nicht ab habe es überprüft

1.) der Zeiger ptr_base ist gültig, also kein Nullpointer oder ähnliches

2.)

extern "C" typedef unsigned long (*GUI_PLG) (HINSTANCE hdll, XComGuiBase**, XGuiMessageSystem*);

otze

wie sieht make_pair aus?
ging da nich ein normales std::pair?