Compiler findet gelegentlich klassenlokal definierte Typen nicht

[Codehunter]

Moin!

Mir passiert es immer wieder, dass bei einem einfachen Compilerlauf (STRG-F9) klassenlokal definierte Typen nicht gefunden werden:

Delphi-Quellcode:

unit A;

interface

uses
  System.Classes;

type
  TMyClass = class(Object)
  public type
    TMyEnum = (enA, enB, enC);
  end;

{...}

unit B;

interface

{...}

implementation

uses
  A;

procedure Produce;
var
  LEnum = TMyClass.TMyEnum; // <-- E2003 Undeklarierter Bezeichner: 'TMyClass.TMyEnum'
  LEnum2 = TMyEnum; // <-- E2003 Undeklarierter Bezeichner: 'TMyEnum'
begin
  {...}
end;

Das Problem tritt frustrierenderweise nur sporadisch auf. Dagegen hilft nur, entweder ein Fullbuild oder vor dem Compilieren die DCUs zu löschen. Das ist insofern etwas lästig, weil es sich um ein Package-Projekt handelt, das ich dann jedesmal deinstallieren muss, Delphi schließen und wieder auf, kompilieren, installieren, nochmal schließen und wieder auf.

Wenn ich die Deklaration von TMyEnum aus der Klasse heraus nehme und in eine separate Unit verlege, tritt das Problem nicht auf. Allerdings wäre das der Ordnung und Übersichtlichkeit halber nur die B-Lösung.

Grüße
Cody

[Uwe Raabe]

Zitat von Codehunter:

Dagegen hilft nur, entweder ein Fullbuild oder vor dem Compilieren die DCUs zu löschen.

Hast du in dem Projekt zyklische Unit-Abhängigkeiten?

[Codehunter]

Zitat von Uwe Raabe:

Hast du in dem Projekt zyklische Unit-Abhängigkeiten?

Jain. Kommt vor bei implementation-uses, nie bei interface-uses. Ließe sich aber auch nur schlecht vermeiden, es sei denn ich wollte alle Klassen in eine Unit klatschen.

[Uwe Raabe]

Zitat von Codehunter:

Jain. Kommt vor bei implementation-uses, nie bei interface-uses. Ließe sich aber auch nur schlecht vermeiden, es sei denn ich wollte alle Klassen in eine Unit klatschen.

Zyklische Abhängigkeiten im interface Abschnitt verhindert ja schon der Compiler, daher sind halt nur implementation-Zyklen möglich - insofern ist das also ein klares Ja.

Das von dir beschriebene Verhalten ist mit hoher Wahrscheinlichkeit auf diese Zyklen zurückzuführen. Auch das CodeInsight gibt an der Stelle in der Regel entnervt auf und das Compilieren dauert häufig auch länger.

Ich behaupte mal, daß es mindestens eine Möglichkeit gibt diese Zyklen aufzulösen, ohne alles in eine Unit zu verfrachten. Bisher ist mir noch kein Fall untergekommen, bei dem das nicht ging.

Übrigens: Die VCL-Sourcen und auch eine Vielzahl der 3rd-party Bibliotheken sind hier ein ganz schlechtes Beispiel und ich bin leider nicht in der Position das zu ändern.

[Codehunter]

Vielleicht erklären sich so auch gelegentliche Internal-Compilerfehler.

Ich nehme das mal zum Anlass ein paar Dinge grundsätzlich zu überdenken und umzustrukturieren. Wenn es sich nicht vermeiden lässt, einige Dinge in einer Unit zusammen zu fassen, dann werde ich ein paar $REGION setzen. So lässt sich auch Übersichtlichkeit schaffen.

[Codehunter]

Nachtrag: Soweit ich das überblicken kann kommen die zirkulären Uses vor allem daher, dass grundlegende Prinzipien der Objektorientierung nicht eingehalten wurden. So gibt es z.B. Methoden TKlasseA.SpeichereInKlasseB anstatt es anders rum zu machen (TKlasseB.LadeVonKlasseA). An anderen Stellen wird mit dem Owner als erzeugende Instanz per Typcast gearbeitet, um auf dessen Properties zugreifen zu können. Das kann ich mit internen Eventhandlern ablösen.

Also insofern: Danke Uwe für den Wink mit dem Zaunpfahl. Man kann es immer besser machen.

[Codehunter]

@Uwe: Scheint bisher so als hättest du Recht gehabt. Projekt bereinigt, zirkuläre Uses entfernt, bisher keine Compilerfehler mehr.

Gibt es denn irgendwo eine Compileroption, mit der man zirkuläre implementation-uses verbieten kann, genauso wie es im interface ohnehin schon ist? Denn manchmal schleichen sich solche Probleme ein ohne dass man es will und/oder bemerkt. So dass man wenigstens darauf aufmerksam wird.

Grüße
Cody

[Uwe Raabe]

Zitat von Codehunter:

Gibt es denn irgendwo eine Compileroption, mit der man zirkuläre implementation-uses verbieten kann, genauso wie es im interface ohnehin schon ist?

Nein, das kann man auf Compiler-Ebene leider nicht verbieten. Beim interface-Abschnitt ergibt sich das aus der Struktur des One-Pass-Compilers schon von selbst.

Ich verwende entweder den Unit Dependency Analyzer im MMX Code Explorer oder den Pascal Analyzer von Peganza zum Aufspüren solcher Zyklen. Ich habe aber schon ein Feature-Request für den MMX Code Explorer angelegt: Add Cyclic Unit Dependency to Live Metrics.