Circular unit reference

[FrankS]

Hallo allerseits,
ich versuche ein C# Programm auf FPC umzusetzen und bin dabei auf folgendes Problem gestossen.

Code: Alles auswählen

TBaseThing = class(TObject)
end;

TThing = class(TBaseThing) 
private
FContainer: TThingHolder;
end;

TThingHolder = class(TThing)
end;

Alle Klassen stehen in separaten Dateien.

Damit gibt es jetzt natürlich eine Circular unit reference zwischen der TThing und TThingHolder Unit.
Kann dieses Problem irgendwie gelöst werden?

Ist wahrscheinlich irrelevant mein System:
Windows 10
Lazarus 2.2.6
FPC 3.2.2

[corpsman]

Nicht schön aber löst dein Problem

binde die circuläre unit unterhalb von implementation ein und schreibe oberhalb anstatt

TThing = class(TBaseThing)
private
FContainer: TThingHolder;
end;

TThing = class(TBaseThing)
private
FContainer: TObject;
end;

Dann caste in deinem Code alles auf TThingHolder

[Zvoni]

Denke ich jetzt zu sehr um die Ecke?

Code: Alles auswählen

program Project1;
{$mode objfpc}{$H+}
Uses Sysutils, Classes;

Type
    TBaseThing = class(TObject)
    end;

    TThingHolder = class;  //Forward Declaration

    TThing = class(TBaseThing)
    private
    FContainer: TThingHolder;
    end;

    TThingHolder = class(TThing)
    end;

begin
  Readln;
end.

Und Lazarus 2.2.6?? Ernsthaft?

[corpsman]

@Zvoni,

so wie ich ihn verstanden habe liegen alle Klassen in einer eigenen Unit, aber nicht der selben, damit geht das vorwärtsdeclarieren nicht, da FPC das nur im selben "skope" zuläst ..

[Zvoni]

@Zvoni,

so wie ich ihn verstanden habe liegen alle Klassen in einer eigenen Unit, aber nicht der selben, damit geht das vorwärtsdeclarieren nicht, da FPC das nur im selben "skope" zuläst ..

Ach Mist.. übersehen.

Tja, entweder deine Variante oder die zwei betroffenen Klassen in eine gemeinsame Unit.
Da er von C# portiert muss er ja nicht diesselbe Strategie verfolgen (sofern die Klassen bereits in C# jeweils in einem eigenen Modul waren).
Und mehrere Klassen in einer Unit (insbesondere in genannter Konstellation) ist ja jetzt nichts unanständiges

[PascalDragon]

Alle Klassen stehen in separaten Dateien.

Das ist eben für FPC kein sinnvoller Ansatz. Klassen mit einer engen Bindung sollten in die gleiche Unit.

[fliegermichl]

Alle Klassen stehen in separaten Dateien.

Das ist eben für FPC kein sinnvoller Ansatz. Klassen mit einer engen Bindung sollten in die gleiche Unit.

Ich hab das auch schon manchmal als unschön empfunden.
Ich habe eine Basisklasse, von der sehr viele spezialisierte Klassen abgeleitet werden und es wäre schon deutlich übersichtlicher, wenn man die jeweils in eigenen Units unterbringen könnte. Bislang habe ich dann wenigstens die Implementierungen in *.inc Dateien untergebracht.

[Zvoni]

Alle Klassen stehen in separaten Dateien.

Das ist eben für FPC kein sinnvoller Ansatz. Klassen mit einer engen Bindung sollten in die gleiche Unit.

Ich hab das auch schon manchmal als unschön empfunden.
Ich habe eine Basisklasse, von der sehr viele spezialisierte Klassen abgeleitet werden und es wäre schon deutlich übersichtlicher, wenn man die jeweils in eigenen Units unterbringen könnte. Bislang habe ich dann wenigstens die Implementierungen in *.inc Dateien untergebracht.

Das ist aber nicht das Szenario hier.
Das Szenario ist Zirkel-Bezug (Klasse A braucht Klasse B, und Klasse B braucht Klasse A)
Wenn die Beziehung eine Einbahnstrasse ist, dann ist es ja kein Problem, jede Klasse in ihre eigene Unit zu packen

[m.fuchs]

Alle Klassen stehen in separaten Dateien.

Das ist eben für FPC kein sinnvoller Ansatz. Klassen mit einer engen Bindung sollten in die gleiche Unit.

Die separaten Dateien sind mit .inc wie @fliegermichl vorgeschlagen ja auch kein Problem.

Das Problem des OP ist ja eigentlich, dass .NET und Pascal unterschiedliche Konzepte haben. Units in dem Sinne gibt es dort nicht, ich würde die an ehesten mit Namespaces vergleichen.

Ergibt für mich dann das Mapping:
gleicher Namespace => gleiche Unit
eigene .cs => eigene .inc

[FrankS]

Hallo,
danke für die Antworten.
Ich werde mal die Klassen in eine Unit packen und der Übersichtlichkeit wegen die Implementierungen in separate .inc Dateien auslagern.
Der Namespace enthält noch diverse weitere Klassen.