Abstrakter Fehler bei leerer Prozedur

[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.

[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.

[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

[Codehunter]

So das Problem hat sich auf mysteriöse Weise selbst erledigt. Nachdem ich alle DCUs (auch die von den Komponenten) gelöscht und alle Projekte neu erzeugt hatte, war der Fehler plötzlich verschwunden. Sowas hasse ich immer am meisten, wenn man nicht mal mehr nachvollziehen kann was schuld war.

Das genannte Beispiel von DeddyH war übrigens auch nicht lauffähig und produzierte ebenfalls abstrakte Fehler. Die sind nun ebenso verschwunden.

Schon seltsam.

[guinnes]

Zitat von Codehunter:

Das genannte Beispiel von DeddyH war übrigens auch nicht lauffähig und produzierte ebenfalls abstrakte Fehler.

Weil DeddyH in der überschriebenen Methode inherited aufruft. Damit wird natürlich der abstrakte Fehler ausgelöst

[Stevie]

Zitat von guinnes:

Zitat von Codehunter:

Das genannte Beispiel von DeddyH war übrigens auch nicht lauffähig und produzierte ebenfalls abstrakte Fehler.

Weil DeddyH in der überschriebenen Methode inherited aufruft. Damit wird natürlich der abstrakte Fehler ausgelöst

Ähm, nö? Ein inherited führt nicht zu einem abstract error, es sei denn, man benamt die aufzurufende Methode (hier nicht geschehen) explizit, wie Günther oben schon erwähnte.
Möglicherweise ist da irgendwas mit XE4 und Win64 im argen?

[DeddyH]

Wie ich in #6 schon schrieb, löste Delphi 5 da noch einen abstrakten Fehler aus. Mindestens ab Delphi 7 (6 habe ich nicht) passiert das aber nicht mehr.

[Codehunter]

Nachdem der Fehler dann gestern am späteren Abend wieder auftrat, habe ich das ganze Projekt mal probeweise auf Win32 umgestellt (eigentlich bauen wir hier ausschließlich x64) und tatsächlich tritt das dort nicht auf bzw. zumindest bis jetzt nicht reproduzierbar. Danach ist mir aufgefallen, dass der abstrakte Fehler nur dann auftritt, wenn ich für Debug kompiliere, nicht aber bei Release. Deshalb meldete ich gestern voreilig "Fehler beseitigt", da stand nach dem Komplett-Build das Projekt zufällig auf Release.

So bin ich auf die beiden DLLs FastMM_FullDebugMode.dll und FastMM_FullDebugMode64.dll gekommen. Nehme ich die FastMM_FullDebugMode64.dll aus dem Suchpfad, ist der Fehler auch im Debug-Build nicht mehr nachzuvollziehen. Dann funktionieren aber auch die Memdumps nicht mehr. So wie es aussieht ist da ein Bug im FastMM im 64-Bit-Modus.

[jaenicke]

Die Ausgabepfade für Units enthalten aber korrekt $(Platform) und $(Config)?