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:

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:

Zitat von FrEEzE2046

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

gibt es keine Möglichkeit.

Zitat:

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:

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:

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:

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:

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:

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 :mrgreen:

[Phoenix]

Zitat:

Zitat von jfheins

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

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

[jfheins]

Zitat:

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

[SirThornberry]

Die richtige Lösung wurde meiner Meinung nach schon vorstellt. Einfach eine weitere Unit hinzufügen in der für beide Klassen jeweils eine abstrakte Basisklasse vorhanden ist. Und die beiden abgeleiteten Klassen beinhalten dann kein Member der anderen Klasse sondern ein Member der anderen Basisklasse.

[stahli]

Das war nicht die Frage. Man kann sich mit verschiedenen Konstrukten behelfen, die aber alles andere als optimal und übersichtlich sind. Wenn z.B. die echte Klasseninstanz zur Basisklasse neue Methoden beseitzt, kommt man an diese ohne Typecasts nicht heran.

Die Frage war, ob Delphi das möglicherweise künftig mitbringen könnte...

[SirThornberry]

Zitat:

Zitat von stahli (Beitrag 1052136)

Das war nicht die Frage....
Die Frage war, ob Delphi das möglicherweise künftig mitbringen könnte...

Ich habe auf den Ausgangspost (und damit die Ausgangsfrage) geantwortet und nicht auf alle Folgebeiträge :) Denn ich denke es geht in erster Linie darum das die Ausgangsfrage geklärt ist (schließlich wurde sie nicht umsonst gestellt). Es wird den Fragesteller sicher nicht all zu weit bringen was in 2 Jahren möglich ist wenn die Ausgangsfrage dabei ungeklärt bleibt.