Externe Deklaration von Klassen

[FrEEzE2046]

Hallo,

ich habe ein (in Delphi) aufwändiges Problem. Und zwar:

Delphi-Quellcode:

//Unit1:

uses Unit2;

TKlasseA = class(TObject)
     KlasseB : TKlasse B;
end;


//Unit2:

TKlasseB = class(TObject)
     Parent : PKlasseA;
end;

So, wie man sieht brauche ich in Klasse B einen Pointer auf seinen Parent. Es ist keine Option (für mich) beides in eine Unit zu packen. Da hat man natürlich die Möglichkeit, sowas per Forward-Deklaration zu lösen.

Wenn ich Unit1 in Unit2 im Interface einbinde, dann hab ich natürlich eine Überkreuzung drin. Ich muss doch irgendwie eine Extern-Deklaration machen können, um dem Compiler zu sagen, dass da etwas existiert, was später noch dem Linker mitgeteilt wird.

Besteht evtl die Möglichkeit den Code nur zu kompilieren und später zu linken?
Ich hoffe ihr könnt mir weiterhelfen.

[jfheins]

Zitat von FrEEzE2046:

Ich muss doch irgendwie eine Extern-Deklaration machen können, um dem Compiler zu sagen, dass da etwas existiert, was später noch dem Linker mitgeteilt wird.

Ja. innerhalb einer Unit geht das mit einer Forward-deklaration. Aber da du ja sagtest

Zitat von FrEEzE2046:

Es ist keine Option (für mich) beides in eine Unit zu packen.

gibt es keine Möglichkeit.

Zitat von FrEEzE2046:

Ich muss doch irgendwie eine Extern-Deklaration machen können, um dem Compiler zu sagen, dass da etwas existiert, was später noch dem Linker mitgeteilt wird.
Besteht evtl die Möglichkeit den Code nur zu kompilieren und später zu linken?

Nein, das geht nicht - Delphi hat einen Single-pass-Compiler.

Einzige Lösung ist: Überwinde deinen Ordnungsdrang und apcke beides in eine Unit. Und wenn du meinst, dass das zu unübersichtlich wird, guck dir mal die VCL-units an

[Uwe Raabe]

Du kannst natürlich acuh nochmal dein Design überdenken: solange TKlasseB nicht auf Parent.KlasseB zugreifen muss, kannst du das Problem mit einer abstrakten TKlasseA lösen.

[FrEEzE2046]

Zitat von jfheins:

Nein, das geht nicht - Delphi hat einen Single-pass-Compiler.

Einzige Lösung ist: Überwinde deinen Ordnungsdrang und apcke beides in eine Unit. Und wenn du meinst, dass das zu unübersichtlich wird, guck dir mal die VCL-units an

Das kann doch nicht sein, dass man dem Compiler nicht mal sagen kann, dass er das jetzt einfach mal so kompilieren soll. Es ist sowieso ein Integer-Typ (Pointer) und mehr muss er zu diesem Zeitpunkt überhaupt nicht wissen.

Es wird ihm später ja noch mitgeteilt, was genau TKlasseA für ein Typ ist.

Zitat von Uwe Raabe:

Du kannst natürlich acuh nochmal dein Design überdenken: solange TKlasseB nicht auf Parent.KlasseB zugreifen muss, kannst du das Problem mit einer abstrakten TKlasseA lösen.

Ist mir klar, ich will (nur)dafür aber keine VMT-Table anlegen lassen.

[sirius]

Zitat von FrEEzE2046:

Das kann doch nicht sein, dass man dem Compiler nicht mal sagen kann, dass er das jetzt einfach mal so kompilieren soll. Es ist sowieso ein Integer-Typ (Pointer) und mehr muss er zu diesem Zeitpunkt überhaupt nicht wissen.

Dann nehme doch den Typ TObject. Wenn es sowieso nix anderes ist....

[FrEEzE2046]

Zitat von sirius:

Dann nehme doch den Typ TObject. Wenn es sowieso nix anderes ist....

Nein, ich meinte dass sowieso jedes Objekt ein Integer - da Pointer - ist.

[jfheins]

Zitat von FrEEzE2046:

Das kann doch nicht sein, dass man dem Compiler nicht mal sagen kann, dass er das jetzt einfach mal so kompilieren soll. Es ist sowieso ein Integer-Typ (Pointer) und mehr muss er zu diesem Zeitpunkt überhaupt nicht wissen.

Doch, das kann sein. Innerhalb der selben Unit ist das nicht ganz so streng (man kann Forward-Deklaration benutzen), aber ansonsten muss der Compiler alles bereits kennen, dem er begegnet.

Ach ja, eine Alternative zu "Beides in eine Unit packen" gibt's noch: Benutze C# .net

[Phoenix]

Zitat von jfheins:

Ach ja, eine Alternative zu "Beides in eine Unit packen" gibt's noch: Benutze C#

Also dann doch lieber Delphi Prism. Das hat auch einen schönen modernen Multipass-Compiler

[jfheins]

Zitat von Phoenix:

Also dann doch lieber Delphi Prism. Das hat auch einen schönen modernen Multipass-Compiler

Okay, hab's verallgemeinert

[stahli]

Bei Prism XE ist genau dieses Beispiel dabei. Ansonsten ist mir aber Delphi "sympatischer".

Ist es denkbar, dass die Embjaner Delphi künftig auf einen Multipasscompiler umstellen?
Die unzulässigen Überkreuz-Bezüge sind m.E. das größte (bzw. einzige) Problem im Delphi.
Oder ist das technisch ausgeschlossen?

Eine entsprechende Möglichkeit würde m.E. VIELES deutlich vereinfachen (möglicher Verzicht auf Typecasts und Events).

(Ich weiß, dass manche Entwickler solche Querbezüge ablehnen, aber man müsste sie ja nicht nutzen.)