Abstrakter Fehler bei leerer Prozedur

[Codehunter]

Hallo!

Ich habe ein kleines Verständnisproblemchen mit abstrakter Vererbung. In einer Vorfahrklasse wird eine virtuelle abstrakte Methode (z.B. "Proc1") eingeführt, aber (logischerweise) noch nicht implementiert. In einer zweiten Methode (z.B. "Proc2") dieser Vorfahrklasse wird die abstrakte Methode aufgerufen.

Eine Nachfahrklasse implementiert jetzt zwar "Proc1", fügt aber keinen Code ein da sie "Proc1" eigentlich nicht benötigt. Allerdings wird für die Nachfahrklasse nun im Hauptprogramm die "Proc2" aufgerufen und damit auch indirekt "Proc1". Und RUMMS gibts da einen abstrakten Fehler.

Ich denke mal, der Compiler optimiert die leere Implementierung von "Proc1" in der Nachfahrklasse einfach weg, denn wenn ich darin irgendwelchen Nonsenscode stehen habe funktioniert alles.

Mache ich da jetzt einen konstruktivischen Fehler oder muss ich an der Stelle das "Wegoptimieren" von "Proc1" unterbinden?

Grüße
Cody

[jaenicke]

Wegoptimiert wird das eigentlich nicht, ich habe da auch nicht immer gleich Code drin.

Dumme Frage, aber das override hast du nicht vergessen, oder?

[DeddyH]

Gerade unter XE versucht:

Delphi-Quellcode:

type
  TClassA = class
  protected
    procedure Proc1; virtual; abstract;
  public
    procedure Proc2;
  end;

  TClassB = class(TClassA)
  protected
    procedure Proc1; override;
  end;

{ TClassA }

procedure TClassA.Proc2;
begin
  Proc1;
end;

{ TClassB }

procedure TClassB.Proc1;
begin
  inherited;

end;

procedure TFormTest.Button1Click(Sender: TObject);
var
  ClassB: TClassB;
begin
  ClassB := TClassB.Create;
  try
    ClassB.Proc2;
  finally
    ClassB.Free;
  end;
end;

Es passiert zwar nichts (was auch?), aber es gibt auch keinen Fehler.

[Popov]

Ich hab zwar noch nicht ganz verstanden wie die Zusammenhänge sind, aber das Wegoptimieren kann ich mir schwer vorstellen. Guck dir mal TObject Create oder Destroy an, beide leer, und auf beide wird vermutlich millionenfach über Inherited zugegriffen. Würden leere Prozeduren weg optimiert, würde es ständig krachen.

Ist aber nur meine persönliche Einschätzung. Muss nicht richtig sein.

Auf der anderen Seite, schon die Klasse Schritt für Schritt mit F7 durchlaufen lassen?

[Der schöne Günther]

Hinweis: "inherited" an sich ist kein Problem wenn die überschriebene Methode der Elternklasse komplett abstrakt ist. Es wird aber ein EAbstractError ausgelöst wenn man den Namen der Methode ausschreibt!

Delphi-Quellcode:

interface

   TBaseClass = class
      public procedure someMethod(); virtual; abstract;
   end;

   TChildClass = class(TBaseClass)
      public procedure someMethod(); override;
   end;

implementation

   procedure TChildClass.someMethod();
   begin
      inherited; // Kein Problem
      inherited someMethod(); // Wirft EAbstractError
   end;

PS: Wegoptimiert wird das ganz sicher nicht. Das kannst du prüfen, ob nach Shift+F9 da noch die blauen Haltepunkte zu sehen sind.

Und: Ich denke eher, du erstellst in Wirklichkeit eine Instanz er Elternklasse mit der noch abstrakten Methode anstatt der erbenden Klasse, oder?

[DeddyH]

In Delphi 5 wirft auch das inherited alleine einen abstrakten Fehler (obwohl die Klassenvervollständigung es ja selbst eingefügt hat). Ich denke eher, dass tatsächlich das override vergessen wurde wie oben bereits vermutet, dadurch wird die Methode nicht überladen überschrieben, sondern überschrieben verdeckt und somit die abstrakte der Elternklasse aufgerufen.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1245796)

Dumme Frage, aber das override hast du nicht vergessen, oder?

Nein nicht vergessen :-D

Zitat:

Zitat von Der schöne Günther (Beitrag 1245808)

Ich denke eher, du erstellst in Wirklichkeit eine Instanz er Elternklasse mit der noch abstrakten Methode anstatt der erbenden Klasse, oder?

Das stimmt sogar und müsste die beschriebenen Probleme eigentlich erklären. Also habe ich Proc1 in der Vorfahrklasse testweise nicht abstract gemacht sondern nur noch virtual und die leere Prozedur-implementation dort schon angelegt. Auf ein override der leeren Proc1 mit einer weiteren leeren Proc1 in der Nachfahrklasse habe ich dann mal verzichtet. Ansonsten das selbe Konstrukt, wie DeddyH in seinem ersten Beispiel schon so schön darstellt. Resultat: Abstrakter Fehler.

Ich kanns mir nur mit Compileroptimierung erklären, denn während folgender Code den Abstrakten Fehler produziert:

Delphi-Quellcode:

procedure TVorfahrKlasse.Proc1;
begin

end;

liefert folgender Sinnloscode keinen Fehler mehr:

Delphi-Quellcode:

procedure TVorfahrKlasse.Proc1;
var
  bDummy: Boolean;
begin
  bDummy:= TRUE;
end;

[Der schöne Günther]

Sind denn nach [Shift]+[F9] die blauen Haltepunkte noch da?

Dann mal zum Nachstellen: Wir reden über Delphi XE4 (Updates, Hotfixes?), kompiliert für Win32?

[Sir Rufo]

Zitat:

Zitat von Codehunter (Beitrag 1245824)

Ich kanns mir nur mit Compileroptimierung erklären, denn während folgender Code den Abstrakten Fehler produziert:

Delphi-Quellcode:

procedure TVorfahrKlasse.Proc1;
begin

end;

liefert folgender Sinnloscode keinen Fehler mehr:

Delphi-Quellcode:

procedure TVorfahrKlasse.Proc1;
var
  bDummy: Boolean;
begin
  bDummy:= TRUE;
end;

Zeig doch mal den ganzen Code und nicht nur das linke Ohr des Eisbären :)

[baumina]

Zitat:

Zitat von Sir Rufo (Beitrag 1245828)

Zeig doch mal den ganzen Code und nicht nur das linke Ohr des Eisbären :)

Erinnert mich an Dalli Klick :-D