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.

[Codehunter]

Zitat von jaenicke:

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

Nein nicht vergessen

Zitat von Der schöne Günther:

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?

[Codehunter]

Zitat von 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?

Blaue Pünktchen sind noch da nach Shift-F4 (beim begin und beim end der Proc1), XE4 Pro mit allen Updates und Hotfixes. Allerdings für Win64 kompiliert.

Zitat von Der schöne Günther:

Da das standardmäßig eine Compiler-Warnung gibt (ich setze es immer auf FEHLER hoch) denke doch ich nicht, dass er das tut.

Ich kenne das von D7 eigentlich noch so, dass sich der Compiler beschwert hat wenn man eine abstrakte Methode einer Basisklasse im Nachfahren nicht implementiert hat. Bei XE4 ist das nicht mehr so.

Zitat von Sir Rufo:

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

Kann ich nicht, da spaltet mir mein Chef mit dem Wurfbeil den Schädel Wenn ich das auf das Wesentliche eindampfe bleibt eigentlich genau das übrig was DeddyH ganz oben auch schon gepostet hat:

Zitat von DeddyH:

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;

Außer dass in procedure TClassB.Proc1; bei mir kein inherited drin stand, wobei das mit und ohne den selben Fehler produziert hat.

[Sir Rufo]

Zitat von Codehunter:

Zitat von Sir Rufo:

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

Kann ich nicht, da spaltet mir mein Chef mit dem Wurfbeil den Schädel Wenn ich das auf das Wesentliche eindampfe bleibt eigentlich genau das übrig was DeddyH ganz oben auch schon gepostet hat:

Zitat von DeddyH:

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;

Außer dass in procedure TClassB.Proc1; bei mir kein inherited drin stand, wobei das mit und ohne den selben Fehler produziert hat.

Funktioniert denn dieser Code bei dir?
Wenn ja, dann passe den weiter an die Original-Klassen an, bis dort der gleiche Fehler auftaucht.
Dieses Beispiel kannst du uns dann zeigen.

Das nennt sich SSCCE

[Sir Rufo]

Zitat von Codehunter:

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 von Sir Rufo:

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

Erinnert mich an Dalli Klick

[jaenicke]

Zitat von Codehunter:

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. [...] Resultat: Abstrakter Fehler.

Wenn du dort irgendwelche abstrakten Methoden drin hast, darfst du die Elternklasse auch nicht direkt erzeugen.