🚀 go-pugleaf

In <45qosk$t10@robot.mayn.de> rob@robot.mayn.de (Roman 'RoB' Bartke) writes:
>"g++ -Wall -o c c.cc -lg++; c" liefert:
>Client::ShowError()
>SpecialClient::ShowError()

>Ich hätte hier
>SpecialClient::ShowError()
>SpecialClient::ShowError()
>erwartet, da es beidemale um einen SpecialClient ging.

Aeh... vielleicht hab ich ja was komplett falsch verstanden... aber
woher soll denn die Basisklasse die Funktionen von SpezialClient kennen,
seien sie jetzt virtuell oder nicht?

Vielleicht hab ich ja auch Deine Frage einfach nicht verstanden...

.... verwirrt, Benni
-- 
benni@informatik.uni-frankfurt.de|http://www.uni-frankfurt.de/gnomic/hello.html
    "Deshalb, Leute, die glauben, dass Computer werden nicht koennen, wie
      Menschen zu denken, auch glaubt nicht in Maschine-Uebersetzung."

Hallo!

Roman 'RoB' Bartke (rob@robot.mayn.de) wrote:
: Meine lieben VIRTUosen!
:
: Gegeben sei folgender Programmrumpf, bei dem das Verhalten der 
: ShowError-Methode des Clients durch Vererbung modifiziert werden soll.
: Das Connect() simuliert hierzu immer einen Fehler.
:
:
: c.cc:
: ------------------------------------------------------------------------
: #include <iostream.h>
:
: class Client
: {
: public:
: 	Client() { Connect(); }
: 	virtual ~Client() { }
: 	void Connect() { ShowError(); }
: protected:
: 	virtual void ShowError() { cerr << "Client::ShowError()\n"; }
: };
:
: class SpecialClient : public Client
: {
: public:
: 	SpecialClient():Client() { }
: protected:
: 	void ShowError() { cerr << "SpecialClient::ShowError()\n"; }
: };
:
: int main(int argc, char *argv[])
: {
: 	SpecialClient client;
: 	client.Connect();
: 	return 0;
: }
: ------------------------------------------------------------------------
:
: "g++ -Wall -o c c.cc -lg++; c" liefert:
: Client::ShowError()
: SpecialClient::ShowError()
:
: Ich hätte hier
: SpecialClient::ShowError()
: SpecialClient::ShowError()
: erwartet, da es beidemale um einen SpecialClient ging.
:
: Warum ruft der Konstruktor nicht die neue virtuelle Methode auf, 
: sondern noch die alte? 

: Das ist im Beispiel tragisch, da der Konstruktor bei neudefinierten
: virtuellen Methoden nicht automatisch "connecten" darf...

Die Klasse "Client" kann keine virtuellen Funktionen von "SpecialClient"
aufrufen. Die virtuellen Funktionen einer Klasse werden in der sogenannten
'Virtual Methods Table' (VMT) abgelegt. Diese Tabelle wird vom Konstruktor
der entsprechenden Klasse angelegt. Bei einer abgeleiteten Klasse werden,
wie Dein Beispiel auch zeigt, die Konstruktoren der Basisklassen vor
demjenigen der abgeleiteten aufgerufen. Das bedeutet, dass die VMT der
abgeleiteten Klasse zu diesem Zeitpunkt noch nicht erzeugt worden sein
kann und daher den Basisklassen unbekannt sein muss. Literatur dazu gibt
es z.B. von Stroustrup, Lippman und einigen anderen, wahlweise auf Deutsch
oder Englisch.

mfg
Juergen

Am 15. Okt 1995 schrieb Roman Bartke (rob@robot.mayn.de):

> Meine lieben VIRTUosen!

> Gegeben sei folgender Programmrumpf, bei dem das Verhalten der 
> ShowError-Methode des Clients durch Vererbung modifiziert werden soll.
> Das Connect() simuliert hierzu immer einen Fehler.


> c.cc:
> ------------------------------------------------------------------------
> #include <iostream.h>

> class Client
> {
> public:
> 	Client() { Connect(); }
> 	virtual ~Client() { }
> 	void Connect() { ShowError(); }
> protected:
> 	virtual void ShowError() { cerr << "Client::ShowError()\n"; }
> };

> class SpecialClient : public Client
> {
> public:
> 	SpecialClient():Client() { }
> protected:
> 	void ShowError() { cerr << "SpecialClient::ShowError()\n"; }
> };

> int main(int argc, char *argv[])
> {
> 	SpecialClient client;
> 	client.Connect();
> 	return 0;
> }
> ------------------------------------------------------------------------

> "g++ -Wall -o c c.cc -lg++; c" liefert:
> Client::ShowError()
> SpecialClient::ShowError()

> Ich hätte hier
> SpecialClient::ShowError()
> SpecialClient::ShowError()
> erwartet, da es beidemale um einen SpecialClient ging.

> Warum ruft der Konstruktor nicht die neue virtuelle Methode auf, 
> sondern noch die alte? 

Das hängt mit der Art zusammen, wie C++ Objekte initialisiert. Jedes
SpecialClient-Objekt enthält ein Client-Objekt. Wird ein SpecialClinent-
Objekt erzeugt, so wird zuerst das Client-Objekt initialisiert, durch
Aufruf des Konstruktors Client(). Zu diesem Zeitpunkt sind die
virtuellen Funktionen noch nicht überschrieben, d. h. wenn der
Konstruktor Client() direkt oder indirekt ShowError aufruft, so benutzt
er Client::ShowError. 

Erst nach der Initialisierung des Client-Objekts werden die Funktionen
überschrieben und dann der Konstruktorcode von SpecialClient()
aufgerufen.

Ein Ausweg wäre, Initialisierungscode, der von virtuellen Funktionen
abhängt, nicht in den Konstruktor hineinzuschreiben, sondern in eine
spezielle Init-Methode, die dann aber nicht vom Konstruktor aufgerufen
werden darf, sondern getrennt aufgerufen werden muß.

> Das ist im Beispiel tragisch, da der Konstruktor bei neudefinierten
> virtuellen Methoden nicht automatisch "connecten" darf...

Wenn es allein darum geht, so könnte man das über Parameter des
Konstruktors steuern:

    class Client {
      public:
	Client (int autoconnect=1) { if(autoconnect) Connect(); }
	virtual ~Client() {}
	void Connect() { ShowError(); }
      protected:
	virtual void ShowError() { cerr << "Client::ShowError()\n"; }
    };

    class SpecialClient : public Client {
      public:
	SpecialClient(): Client(0)	// kein Autoconnect in Client
          { Connect(); }		// Connect erst in SecialClient
      protected:
	void ShowError() { cerr << "SpecialClient::ShowError()\n"; }
    };

Hier wird Connect erst im Konstruktor SpecialClient() aufgerufen, so daß
die richtigen virtuellen Funktionen benutzt werden.


Karl-Heinz Krause