Kreuzende Beziehung zw. zwei Objekten

[Panthrax]

1.

Delphi-Quellcode:

type
  TAbstract = class abstract
    // abstrakte Klasse.
  end;

2. Wie soll die Klassengröße beim Kompilieren bestimmt werden, wenn sich Typdefinitionen zikulär über mehrere Dateien verwenden? Das geht nicht, nicht mit Einzellaufkompilern. Und das Konzept ist gut so, wie es ist! -- mM.

[mirage228]

Zitat von Panthrax:

1.

Delphi-Quellcode:

type
  TAbstract = class abstract
    // abstrakte Klasse.
  end;

Seit welcher Version geht das? Unter Delphi 7 / 2005 geht es noch nicht...

[SebE]

bei abstrakten Klassen spielt die benötigte Größe gar keine Rolle.

[Panthrax]

Zitat von mirage228:

Zitat von Panthrax:

1.

Delphi-Quellcode:

type
  TAbstract = class abstract
    // abstrakte Klasse.
  end;

Seit welcher Version geht das? Unter Delphi 7 / 2005 geht es noch nicht...

Turbo Delphi Explorer, Delphi 2009.

Zitat von SebE:

bei abstrakten Klassen spielt die benötigte Größe gar keine Rolle.

Natürlich tut sie das...

[SebE]

ok, wir reden hier sicher von verschiedenen Schuhen.

Erklär mir das bitte näher: in wiefern benötigt ein Compiler die Größe einer abstrakten Klasse?
Und für die "richtige" (abgeleitete) Klasse kennt er doch die abstrakte Klasse.

[Panthrax]

Zitat von SebE:

ok, wir reden hier sicher von verschiedenen Schuhen.

Erklär mir das bitte näher: in wiefern benötigt ein Compiler die Größe einer abstrakten Klasse?
Und für die "richtige" (abgeleitete) Klasse kennt er doch die abstrakte Klasse.

Zwei Beispiele in einem:

Delphi-Quellcode:

type
  TAbstract = class abstract
    // Größe = GrößeVon(Felder neu in TAbstract) + GrößeVon(Vorfahre(TAbstract))
    //       = GrößeVon(Felder neu in TAbstract) + GrößeVon(TObject)
  end;

  TConcrete = class(TAbstract)
    // Größe = GrößeVon(Felder neu in TConcrete) + GrößeVon(Vorfahre(TConcrete))
    //       = GrößeVon(Felder neu in TConcrete) + GrößeVon(TAbstract)
  end;

Und jetzt für zwei abstrakte Klassen, die sich gegenseitig verwenden: (Schenk' ich mir...)

Abstrakte Klasse können nicht instantiiert werden. Der Klassenzusatz "abstract" hat nur disziplinarische Wirkung, vergleichbar mit Sichtbarkeitsbeschränkungen. Insofern unterscheiden sich abstrakte Klassen nicht von "gewöhnlichen" Klassen. Die Größe ist für alle gleichsam bedeutsam.

[SebE]

DAnke für die Aufklärung...ich hab mich gewundert, warum du dich so speziell auf abstrakte Klassen fest gelegt hast. Das ist doch (wie du richtig schreibst) wurst, ob Abstrakt oder nicht...


Also: Es ist doch kein Problem von Abstrakten Klassen, dass man deren Größe nicht berechnen kann (das ist ein allgemeines Problem) - das ist der Grund für meinen Einwand.

[brechi]

Delphi-Quellcode:

type
  THallo = class;

  THuhu = class
    a: THallo;
  End;

  THallo = class
    a: THuhu;
  end;

ist das nicht das was ihr sucht?

oder waren 2 units gemeint?

[Panthrax]

Zitat von SebE:

DAnke für die Aufklärung...ich hab mich gewundert, warum du dich so speziell auf abstrakte Klassen fest gelegt hast. Das ist doch (wie du richtig schreibst) wurst, ob Abstrakt oder nicht...

Also: Es ist doch kein Problem von Abstrakten Klassen, dass man deren Größe nicht berechnen kann (das ist ein allgemeines Problem) - das ist der Grund für meinen Einwand.

Man kann die Größe berechnen. -- Natürlich muss man die Größe (abstrakter) Klassen berechnen können. Eben das ist gewährleistet durch das Konzept von Delphi und auch in einer Güte, die einen Einzellaufkompiler ermöglicht. Deshalb kann man keine beliebigen Beziehungen über mehrere Quelltextmodule (hier: Dateien) erstellen. (Auch Mehrlaufkompiler können das nur bedingt.) Der Grundsatz: "Erst definieren, dann verwenden." passt wunderbar hier hinein und hilft außerdem beim Denken. Und innerhalb eines Quelltextmoduls ist es dennoch durch Vorausdeklarationen möglich, dass Klassen sich gegenseitig verwenden. Objektvariablen sind in ihrer Größe nämlich definiert. (Sie sind Zeiger, siehe oben "THallo = class;" = SizeOf(Pointer)) Das gilt eben nicht für beliebige Typen:

Delphi-Quellcode:

type
  TAbstract = class {abstract}
    FField: TAnyType;
  end;

[SebE]

ne, die Lösung steckt in einer übergeordneten (wär schön, wenn noch abstrakten) Klasse.

Ja, es sind mehrere Units im Spiel.