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

fluxy

Das Interface habe ich. Aber um es mal ganz klas auszudrücken ein anderer Fall. Angenommen wir haben nur 1 Interface für das Plugin

class Basis 
{
public:
virtual void test (void) = 0;
};

und die Pluginklasse definiert eine andere methode die nicht im Interface sein darf:

class Abgeleitet
{
public:
virtual void irgendwas (void);
};

und ich habe jetzt meinen Baisklassenzeiger:

Basis* test = new Abgeleitet ();

wie bekomme ich jetzt ohne von der Klasse Abgeleitet zu wissen Zugriff auf die Mentode irgendwas???

otze

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

ssm

fluxy schrieb:

hmmm also das von ssm.... cool..... aber Ohne kommentar verstehe ichs wohl nicht.

Kannst du es vielleicht mal erläutern?!

es ist mir ein bischen schwierig auf Deutsch zu erläutern, weil ich noch nich besonders fit in Deutsch bin. du kannst über pattern Visitor z.B. im Internent lesen:

http://kilana.unibe.ch:9090/ese2003gruppen-smallwikis/southsidecrewssc/patternserklrt/visitor/

wenn du weiter die Fragen hast, kann ich versuchen es zu erklähren

ssm

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.

DJohn

@fluxy

Der Sinn dieser Kapselung ist, dass Du keinen! Zugriff auf die Methode irgendwas bekommst. Um die Methode irgendwas aufzurufen kann Dein Plugin aber die Methode test (oder irgendeine andere passende virtuelle Methode des Interface) überschreiben und von dort aus selbst die Methode irgendwas aufrufen.

Vielleicht ist es so verständlicher ?

DJohn

EDIT: zu langsam. Das bezieht sich auf das letzte Beispiel von fluxy

fluxy

von wem?!

wie wären denn die besseren lösungen?

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

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