Hi,

class a

{

		public:

			a( ... );

};


class b

{

	public:

		b( ... );

};


class c: public a,public b

{

	public:

		c( ... ):a( ... ),b( ... ) { }

};


x *y;

y = new c( ... );

delete y;

wie kann ich jetzt hier meiner instanz c sagen das es jetzt ein a ist bzw. ein b sein soll oder beides???

Sorry,

streicht doch bitte alle mal die letzten drei Zeilen und ersetzt diese doch bitte hiermit:

a*x;

x = new c( ... );

delete x;

Musst einfach alle Methoden der Basisklassen als virtual deklarieren, dann weiss der Compiler daß er sich NICHT nach der Typ-Deklaration richten muss, sondern nach dem TATSÄCHLICHEN Typ des Objekts.

... Beim Überschreiben der virtuellen Methoden in C mußt Du dann den Qualifier mit Scope angeben, damit der Compiler weiß, welcher Part von welchem Klassenpart verwendet und überschrieben werden soll. Lies mal den Source weiter unten, dort wird genau das erklärt: http://fachinformatiker-world.de/forums/showthread.php?s=&threadid=16155&highlight=bing

Hi,

das sind keine Methoden sondern "nur" die Konstruktoren.

Ich versuche mich mal besser auszudrücken

class x stellt nur die Werkzeuge und die Methoden (get/set) bereit und natürlich auch seinen Konstruktor, dieser setzt aber nur die Werte.

class a: public x soll einen Stack machen, hat nur einen Konstruktor.

class b: class x soll einen Queue bilden, hat nur einen Konstruktor.

In class c: public a, public b möchte ich die Werte für die Daten gerne in den Stack und auch in die Queue packen, , hat nur einen Konstruktor.

Wenn ich jetzt sowas hier mache:

x *instanz;

(Das hier steht in einer anderen Klasse ...)

/*1*/ instanz = new a(NULL,100,100);

/*2*/ instanz = new b(instanz,200,200);

/*3*/ instanz = new c(instanz,300,300);

In der dritten Zeile gibt es dann immer eine Fehlermeldung, wegen Mehrdeutigkeit.

Eigentlich klappt alles ganz gut, bis auf die Klasse c halt

Es gibt noch eine zweite Möglichkeit - man muß nicht alles über die Vererbungshierarchie laufen lassen und versuchen gewaltsam eine neue Klasse zu bilden. Meist ist es übersichtlicher und einfacher ein Objekt der Klasse a & b als Member-Objekte in c deklarieren. Dann kann man über die gewünschten Funktionen von c über die Public-Methoden der Member-Objekte alles handhaben. Wenn man an interne Methoden und Daten ranmuß kann man c immer noch als Friend von a und b deklarieren (wäre aber nicht so schön). Grundsätzlich überlegt man sich bei der Programmentwicklung immer ob man über die Hierarchie Vererbt oder über Member-Objekte. Die Hierarchie ist spätestens bei einer weiteren Vererbung von c nach d relativ unübersichtlich und kann echte Verständnischwierigkeiten hervorrufen - da ist die Member-Variante schon besser - und alle Möglichkeiten stehen (fast) im gleichen Maße offen. Außerdem ist das Problem mit Zweideutigkeiten bei Memberobjekten automatisch geklärt und taucht erst gar nicht auf.

Hi,

seid mir nicht böse aber ich weiß immer noch nicht wie es funktiojiert.

Ich weiß das man es auch anders machen könnte .....

Dein Code:

code:--------------------------------------------------------------------------------

class a

{

public:

a( ... );

};

class b

{

public:

b( ... );

};

class c: public a,public b

{

public:

c( ... ):a( ... ),b( ... ) { }

};

x *y;

y = new c( ... );

delete y;

--------------------------------------------------------------------------------

Wenn Du ein C-Objekt als ein anderes benötigst, dann mußt Du einen Dynamic_cast ansetzen, damit das Objekt zu einem Untergeordneten down-gecastet wird. Es wird ein Pointer auf das neu gecastete Objekt zurückgegeben und wenn dieser nicht 0 ist hat´s geklappt (am Besten immer nach dem Cast testen). Grundsätzlich ist ein C-Objekt eine Mischung aus a und b (beinhaltet also beide Eigenschaften komplett).

Hoffentlich ist Dir jetzt geholfen ...

Hi,

man muß nicht alles über die Vererbungshierarchie laufen lassen und versuchen gewaltsam eine neue Klasse zu bilden

Ich werde bzw. habe mir genau diesen Satz zu Herzen genommen, Ich glaube es bringt viel mehr! Es ist besser

Nochmals vielen Dank @Crush