Warum virtuelle Destructoren?

[Muetze1]

1. Entweder einfach im Implementation Teil deklararieren.
2. Oder als private Sub-Klasse definieren
3. Auslagern und diese Unit Unit-privat im Implementation Teil einbinden

Diese Möglichkeiten sehe ich ...

[Cöster]

Zitat:

Zitat von Muetze1

1. Entweder einfach im Implementation Teil deklararieren.

Hört sich schonmal gut an, krieg ich aber irgendwie nicht richtig gebacken. Ich hab die Deklaration von TNode einfach unter "implementation" verschoben und noch type davor geschrieben. Dann fängt's allerdings schon damit an, dass TNode (was der Typ einiger Attribute TFIFOs ist) ein undefinierter Bezeichner ist. Zahlreiche weitere Fehlermeldungen folgen.

Zitat:

Zitat von Muetze1

2. Oder als private Sub-Klasse definieren

:wiejetzt: TNode von TFIFO ableiten? Und dann? Den Typen TNode muss ich bereits in TFIFO verwenden können, da er wie gesagt Typ einiger Attribute dort ist. :gruebel: Was genau ist eine private Subklasse?

Ich zeig am besten mal den Code, wie er bisher war:

Delphi-Quellcode:

unit FIFO;

interface

type
   TNode = class
   private
      FNext: TNode;
      FObject: TObject;
      constructor Create(AObject: TObject);
      destructor Destroy; override;
   end;

   TFIFO = class
   private
      FFront: TNode;
      FRear: TNode;
   public
      constructor Create;
      destructor Destroy; override;
      procedure Clear;
      function Dequeue: TObject;
      procedure Enqueue(AObject: TObject);
   end;

implementation


constructor TNode.Create(AObject: TObject);
begin
   inherited Create;
   FObject := AObject;
   FNext := nil;
end;

destructor TNode.Destroy;
begin
   FObject.Free;
   inherited;
end;

constructor TFIFO.Create;
begin
   inherited;
   FFront := nil;
   FRear := nil;
end;

destructor TFIFO.Destroy;
begin
   Clear;
   inherited;
end;

procedure TFIFO.Clear;
begin
   while FFront <> nil do
      Dequeue.Free;
end;

function TFIFO.Dequeue;
begin
   if FFront <> nil then
   begin
      Result := FFront.FObject;
      FFront := FFront.FNext;
   end
   else
      Result := nil;
end;

procedure TFIFO.Enqueue(AObject: TObject);
begin
   if FRear <> nil then
   begin
      FRear.FNext := TNode.Create(AObject);
      FRear := FRear.FNext;
   end
   else
   begin
      FRear := TNode.Create(AObject);
      FFront := FRear;
   end;
end;

end.

Wie genau müsste ich den dann umschreiben?

[Muetze1]

Zitat:

Zitat von Cöster

Zitat:

Zitat von Muetze1

1. Entweder einfach im Implementation Teil deklararieren.

Hört sich schonmal gut an, krieg ich aber irgendwie nicht richtig gebacken. Ich hab die Deklaration von TNode einfach unter "implementation" verschoben und noch type davor geschrieben. Dann fängt's allerdings schon damit an, dass TNode (was der Typ einiger Attribute TFIFOs ist) ein undefinierter Bezeichner ist. Zahlreiche weitere Fehlermeldungen folgen.

Das ist klar. Von daher musst du es bei diesem Weg eh so umschreiben, dass TNode nur intern genutzt wird und nur in der Implementation entsprechend ge-typecasted wird.

Zitat:

Zitat von Cöster

Zitat:

Zitat von Muetze1

2. Oder als private Sub-Klasse definieren

:wiejetzt: TNode von TFIFO ableiten? Und dann? Den Typen TNode muss ich bereits in TFIFO verwenden können, da er wie gesagt Typ einiger Attribute dort ist. :gruebel: Was genau ist eine private Subklasse?

Ich habe nix von ableiten geschrieben.

Delphi-Quellcode:

unit FIFO;

interface

type
  TFIFO = class
  private
    Type
      TNode = class
      private
        FNext: TNode;
        FObject: TObject;

      public
        constructor Create(AObject: TObject);
        destructor Destroy; override;
      end;

  private

      FFront: TNode;
      FRear: TNode;
   public
      constructor Create;
      destructor Destroy; override;
      procedure Clear;
      function Dequeue: TObject;
      procedure Enqueue(AObject: TObject);
   end;

implementation


constructor TNode.Create(AObject: TObject);
begin
   inherited Create;
   FObject := AObject;
   FNext := nil;
end;

destructor TNode.Destroy;
begin
   FObject.Free;
   inherited;
end;

constructor TFIFO.Create;
begin
   inherited;
   FFront := nil;
   FRear := nil;
end;

destructor TFIFO.Destroy;
begin
   Clear;
   inherited;
end;

procedure TFIFO.Clear;
begin
   while FFront <> nil do
      Dequeue.Free;
end;

function TFIFO.Dequeue;
begin
   if FFront <> nil then
   begin
      Result := FFront.FObject;
      FFront := FFront.FNext;
   end
   else
      Result := nil;
end;

procedure TFIFO.Enqueue(AObject: TObject);
begin
   if FRear <> nil then
   begin
      FRear.FNext := TNode.Create(AObject);
      FRear := FRear.FNext;
   end
   else
   begin
      FRear := TNode.Create(AObject);
      FFront := FRear;
   end;
end;

end.

/EDIT: Programmierst du wirklich mit TABs? Das gehört meiner Meinung nach verboten...

/EDIT2: Den Constructor und Desctructor kannst du nicht einfach in eine geringere Sichtbarkeit verschieben...

[Cöster]

Zitat:

Zitat von Muetze1

Ich habe nix von ableiten geschrieben.

Dann war mir bis gerade der Begriff Subklasse wohl nicht ganz klar. Jetzt weiß ich, was du meinst, und werde es mit diesen "privaten Subklassen" machen. Bei der Implementierung der Subklassen-Methoden muss ich im Methodenkopf vor "TNode" dann aber wohl auch noch "TFIFO." ergänzen.

Zitat:

Zitat von Muetze1

Programmierst du wirklich mit TABs? Das gehört meiner Meinung nach verboten...

Ja, warum nicht? Dazu gab's hier ja schon mehrere Diskussionen, die mich überzeugt haben 3 Zeichen lange Tabs zu verwenden.
Aber falls du einen guten Grund dagegen hast, würd ich den gerne hören (falls es hier zu OT wird, dann evtl per PM oder im verlinkten Thread.

[blawen]

Zitat:

Zitat von Muetze1

Programmierst du wirklich mit TABs? Das gehört meiner Meinung nach verboten...

Zitat:

Zitat von Cöster

Ja, warum nicht? Dazu gab's hier ja schon mehrere Diskussionen, die mich überzeugt haben 3 Zeichen lange Tabs zu verwenden.
Aber falls du einen guten Grund dagegen hast, würd ich den gerne hören (falls es hier zu OT wird, dann evtl per PM oder im verlinkten Thread.

Siehe hier

[Muetze1]

Zitat:

Zitat von Cöster

Zitat:

Zitat von Muetze1

Programmierst du wirklich mit TABs? Das gehört meiner Meinung nach verboten...

Ja, warum nicht? Dazu gab's hier ja schon mehrere Diskussionen, die mich überzeugt haben 3 Zeichen lange Tabs zu verwenden.
Aber falls du einen guten Grund dagegen hast, würd ich den gerne hören (falls es hier zu OT wird, dann evtl per PM oder im verlinkten Thread.

Ja, der Grund, der mich zu der Frage führte: ich hatte Probleme den gequoteten Quellcode abzuändern, ohne das meine Ergänzungen völlig falsch eingerückt waren. Auch ist Tab schlecht in Bezug auf editieren, weil man(n) erstmal wissen muss, dass du einen 3 Zeichen Tab verwendest. Ansonsten steht der Rest in dem von blawen verlinkten Beitrag. Für mich war es deutlich umständlicher den Quellcode anzupassen...

[Cöster]

Zitat:

Zitat von Muetze1

ich hatte Probleme den gequoteten Quellcode abzuändern, ohne das meine Ergänzungen völlig falsch eingerückt waren. Auch ist Tab schlecht in Bezug auf editieren, weil man(n) erstmal wissen muss, dass du einen 3 Zeichen Tab verwendest.

Dann werd ich, bevor ich hier das nächste Mal Code poste, vorher daran denken, meine Tabs in Leerzeichen umzuwandeln. Wenn die Tab-Breite im Antwort-schreiben-Fenster auf 8 erhöht wird, könnte es tatsächlich etwas unübersichtlich werden.

Zitat:

Zitat von Muetze1

Für mich war es deutlich umständlicher den Quellcode anzupassen...

Dann erst Recht vielen Dank für deine Hilfe :thumb:

[Hansa]

Ja, Tabs sind echt schön. :mrgreen: Trotzdem Zwischenfrage : wozu konkret dient das zweimalige "override" ? :shock:

[JasonDX]

Zitat:

Zitat von Hansa

Zwischenfrage : wozu konkret dient das zweimalige "override" ? :shock:

Wo siehst du ein zweimaliges Override? Einmal isses fuer TFIFO.Destroy, und einmal fuer TNode.Destroy. Nicht durch die Nested Classes durcheinanderbringen lassen :zwinker:

greetz
Mike

[Hansa]

Ja, was soll denn überschrieben werden ? :shock: Da ist doch nichts vorher.