virtual / override ??

[Chewie]

Eigentlich ist es ganz simpel, wenn man den Überblick hat:

Es gibt grundsätzlich die Unterscheidung zwischen statischen und virtuellen Methoden. Die dynamischen rechne ich jetzt den virtuellen zu, da diese sich im Laufzeitverhalten nicht von den virtuellen unterscheiden.

Klassen sind im wesentlichen nichts weiter als erweiterte Records. Eine Klasse enthält zunächst einen Zeiger auf die Virtual Method Table, dann die Felder und dann die Methoden.
Statische Methoden heißen statisch, weil ihre Adresse zur Compilierzeit feststeht. Eine statische Methode wird vom Compiler also wie eine gewöhnliche Funktion behandelt, wenn der Code erzeugt wird. Es wird nur zusätzlich eine Referenz auf das bezogene Objekt mitgegeben.

Bei virtuelle Methoden dagegen wird erst zur Laufzeit die Adresse ermittelt. Das geschieht mit Hilfe der VMT (s.o)., in der u.a. die Adressen der virtuellen Methoden stehen.

Nun schaue man sich folgendes an:

Delphi-Quellcode:

type
  TMyStaticClass = class
  public
    procedure DoSomething;
  end;

  TMyStaticDerivedClass = class
  public
    procedure DoSomething;
  end;
  
  TMyVirtualClass = class
  public
    procedure DoSomething; virtual;
  end;

  TMyVirtualDerivedClass = class
  public
    procedure DoSomething; override;
  end;

procedure TMyStaticClass.DoSomething;
begin
  ShowMessage('1');
end;

procedure TMyStaticDerivedClass.DoSomething;
begin
  ShowMessage('2');
end;

procedure TMyVirtualClass.DoSomething;
begin
  ShowMessage('3');
end;

procedure TMyVirtualDerivedClass.DoSomething;
begin
  ShowMessage('4');
end;

So, jetzt probieren wir etwas rum:

Delphi-Quellcode:

var
  o: TMyStaticClass;
begin
  o := TMyStaticDerivedClass.Create;
  o.DoSomething;
end;

Hier wird '1' ausgegeben. Warum, es wird doch eine Instanz von TMyStaticDerviedClass erzeugt? Ja, aber der Typ der Variablen ist TMyStaticClass, und Typen werden zur Compilierzeit ausgewertet.

Schauen wir uns das ganze mal virtuell an:

Delphi-Quellcode:

var
  o: TMyVirtualClass;
begin
  o := TMyVirtualDerivedClass.Create;
  o.DoSomething;
end;

Hier wird nun 4 ausgegeben. Wir erinnern uns, jedes Objekt enthält einen Zeiger auf die VMT. Dadurch kann zur Laufzeit, obwohl der tatsächliche Typ unbekannt bzw. maskiert ist, die Adresse der entsprechenden virtuelle Methode ermittelt werden.


Nun zu override:
Um zu kennzeichnen, dass wir eine virtuelle Methode überschreiben wollen, müssen wir dem override angeben. Die Methode bleibt dadurch virtuell, keine Angst. Geben wir aber kein override an, so verdecken wir die virtuelle Methode. Der Compiler teilt uns das mit, weil er denkt, wir wollen das nicht so. Wenn wir das aber doch wollen, müssen wir ihm das explizit sagen, und dafür ist reintroduce da.

[Chewie]

Zitat:

Zitat von dizzy

Zitat:

Zitat von Chewie

Auf einem 32-Bit-Prozessor ist ein "Wort" 4 Byte lang

Seit wann dass denn?

So hab ich das in meinen Rechnerarchitektur-Vorlesungen gelernt. Ein Wort ist die Dateneinheit, die gleichzeitig auf dem Bus von Speicher zum Prozessor übertragen werden kann.

[dizzy]

Zitat:

Zitat von Chewie

Zitat:

Zitat von dizzy

Zitat:

Zitat von Chewie

Auf einem 32-Bit-Prozessor ist ein "Wort" 4 Byte lang

Seit wann dass denn?

So hab ich das in meinen Rechnerarchitektur-Vorlesungen gelernt. Ein Wort ist die Dateneinheit, die gleichzeitig auf dem Bus von Speicher zum Prozessor übertragen werden kann.

Das mag speziell für manche Architekturen zutreffen, aber 1 Wort ist als 2 Byte definiert, da bin ich mir ziemlich sicher 8)

[Chewie]

Hier mal dazu der Auszug bei Wikipedia: http://de.wikipedia.org/wiki/Wort_%28Informatik%29

Könnte durchaus stimmen. Sowas passiert, wenn eine Wissenschaft mit Lichtgeschwindigkeit aus den Universitäten in die Wirtschaft braust 8)

[dizzy]

Ist doch immer wieder schön, wenn 2 gegensätzliche Meinungen derart zusammengeführt werden können, dass keiner von seiner Position abrücken muss, und trotzdem beide Recht erhalten :mrgreen: :stupid:

Dass die Macianer da komisch sind war ja wieder klar... (jaja, ich weiss, eigentlich machen sie's richtig...)

[Hansa]

Zitat:

Zitat von dizzy

Ist doch immer wieder schön, wenn 2 gegensätzliche Meinungen derart zusammengeführt werden können

Ja, das ist echt schön. :lol: Nur, was nützt mir das ganze jetzt ? Ich brauche konkrete Beispiele, wozu das override gut ist und dann die anderen Schlüsselwörter auch.

[fkerber]

Hi!

Eigentlich hat Chewie doch alles erklärt?!
Was ist dir noch unklar?

Ciao Frederic

[Pseudemys Nelsoni]

mit override überschreibst du die (in diesem fall) prozedur des vorgängers, d.h du kannst die vorgänger prozedur mit "inherited prozedur" aufrufen und noch "eigenes zeugs" mit rein machen.... würdest du kein override benutzen, würde die alte prozedur durch deine neue ersetzt werden und den vorgänger könntest du nichtmehr aufrufen (wenn was falsch war, bitte sagen^^)

[Hansa]

Also : "abstract" darf in der Basisklasse nicht implementiert werden. Es ist wie der Name schon sagt abstrakt. Vorerst also ohne konkrete Bedeutung. In abgeleiteten Klassen kann sich das ändern.

Nun habe ich allerdings keine Lust etwas eventuell überflüssiges zu programmieren. Deshalb verwende ich jetzt nur "virtual", um die Grundlage der Vererbung zu schaffen. Die Basisklasse wird also schon für einen konkreten Zweck gefüllt und kann bei Bedarf überschrieben werden.

"abstract" ist eher was für Komponentenentwickler, die beim besten Willen nicht wissen können, was später daraus wird. Da geht es mehr oder weniger nur darum, den Namen einer Methode zu reservieren.

Nun aber, was ist mit "override" :?:

[nailor]

override braucht man normal nicht. das ist nur dann zu gebrauchen, wenn du bewusst in einer abgeleiteten klasse etwas von der basisklasse ÜBERSCHREIBEN willst. also nicht hinzufügen sondern WEGMACHEN.

abstract/virtual hat gegenüber nur virtual den vorteil, dass bei virtual in der abgeleiteten version nichts hinzugefügt werden muss, man also theoretisch eine instanz von einem objekt mit nur gerüst-funktion erstellen kann.
hängt noch ein abstract dran, kann man zwar zunächst nichts programmieren, aber man kann vin den abgeleiteten klassen keine instantiieren, falls nicht jede abstrakte funktion "overrided" ist - d.h. programmiert wurde,