Unit-übergreifende Sichtbarkeit von {$Define …} - geht das?

[Andreas13]

Hallo Community,
eigeintlich möchte ich aus Unit_2 heraus feststellen, ob in der benutzten Unit_1 die in der von Unit_1 eventuell benutzte Unit_X eingebunden ist oder nicht.
Mir ist dazu nichts besseres eingefallen, als in Unit_X ein passendes Define hinzuzufügen und dieses Define in den rufenden Units abzufragen.

Das Gerüst der drei Units sieht dann wie folgt aus:

Delphi-Quellcode:

Unit Unit_x;

{$Define Unit_X_ist_Vorhanden}

Interface
...

Implementation

...

End. {Unit_x}
{-----------}

Unit Unit_1;

Interface
Uses 
  Unit_X;

...

Implementation
... 

End. {Unit_1}
{-----------}


Unit Unit_2;
...

Interface
...

Implementation
Uses 
  Unit_1;
... 
  {$IFDEF Unit_X_ist_Vorhanden}
   //
  {$ELSE}
    ShowMessage('Fehler: Unit_X ist NICHT vorhanden!');
  {$ENDIF}   

End. {Unit_2}
{-----------}

Mein Problem ist "nur", daß in Unit_2 das {$Define Unit_X_ist_Vorhanden} aus Unit_X nicht sichtbar ist.

Wie könnte ich zu einer praktikablen Lösung kommen?

Danke für jeden Tipp & Hinweis im Voraus!

[dummzeuch]

Mit einem Define geht das nicht und mir fällt auch keine andere Möglichkeit ein, das zu prüfen.

Was willst du denn eigentlich damit erreichen?

[himitsu]

Typen und Konstanten kann man als Alias in Unit1 "neu" deklarieren und sie somit aus UnitX in die Unit2 durchreichen.

Methoden, Property-Typen, Methoden-Result-Typen usw., welche über einen Vorfahren aus UnitX in Unit1 abgeleitet wurden, lassen sich indirekt zugreifen. (so lange man nicht diesen Typen eines Parameter/Result direkt verwenden will)




Es gibt ein {$IF Declared(...)} , aber damit kannst du nur auf etwas (Variable/Konstante/Funktion/Typ/...) prüfen, welches sich in deinem Scope befindet.
Also eine Unit in einer anderen Unit (egal ob interface oder implementation) findet sich somit nicht.


DEFINEs sind nicht modulübergreifend.
Ausnahme, wenn sie als Compiler-Option rein kommen. Oder überall via INCLUDE-Datei.

Was einfach ginge, zur Laufzeit, nach einem Export oder einer Ressource suchen, welcher über die andere Unit rein kommt.
Oder über die erweiterte RTTI etwas davon finden.

[Uwe Raabe]

Zitat von Andreas13:

ob in der benutzten Unit_1 die in der von Unit_1 eventuell benutzte Unit_X eingebunden ist oder nicht.

Woran wird denn dieses eventuell fest gemacht?

[Sinspin]

Hey,
Eine Unit hat einen Initialization Abschnitt.
Du könntest damit erreichen das sich jede Unit in eine globale Liste einträgt.
Später, nachdem alle Units geladen sind, kannst du dann in der Liste nachsehen wer alles da ist.
Zwischendurch geht das aber nicht, da es Sache des Compilers/Linkers ist zu entscheiden wann welche Unit geladen/Initialisiert wird.

[dummzeuch]

Zitat von Sinspin:

Eine Unit hat einen Initialization Abschnitt.
Du könntest damit erreichen das sich jede Unit in eine globale Liste einträgt.
Später, nachdem alle Units geladen sind, kannst du dann in der Liste nachsehen wer alles da ist.

Es gibt diese globale Liste bereits. Man kann damit herausfinden, ob eine Unit in ein Executable eingebunden ist oder nicht. Falls es das ist, was der OP erreichen möchte, hier ist Code dafür auf Stack Overflow (als Antwort auf eine Frage, die ich damals gestellt hatte).

[Andreas13]

Mir geht es konkret um die Benutzung der von arcticwolf bereitgestellten Bibliothek https://www.delphipraxis.net/213259-...ml#post1524889

Diese Console Library hat für meine unzähligen Test-Berechnungen einige Vorteile (Umlaute, Farben, größere Schrift etc.) gegenüber der Standard-Console.
Weil es jedoch bei einer direkten Einbindung von Crt.pas zu Namenskonflikten kommt, habe ich eine Zwischen-Unit angelegt und die für mich wichtigsten Routinen exportiert.
Um einfach zwischen der "neuen" und der "alten" Konsole-Ausgabe hin- und herschalten zu können, wollte ich in der Zwischen-Unit die Function WriteLn per Overload in der Weise neu deklarieren, daß bei Abwesenheit der neuen Console Library System.WriteLn(..) benutzt wird, ansonsten das neue Crt.WritelnConsole(..) . Dadurch hätte ich alte Berechnungen wie gehabt und neue mit der neuen Console Library kompilieren können, ohne viel ändern zu müssen.

Wahrscheinlich habe ich viel zu kompliziert gedacht...

Danke für Eure Tipps & Anregungen!

[arcticwolf]

Zitat:

Weil es jedoch bei einer direkten Einbindung von Crt.pas zu Namenskonflikten kommt

Mit welchen Namenskonflikten hast Du zu kämpfen?

Es gibt da in der "Console Library" einen Schalter mit dem Du festlegen kannst ob Write/Writeln vom System oder von meiner Library behandelt werden soll. Per Default steht der Schalter auf True. Du kannst ihn mal ausschalten und testen ob das bei deinem Problem hilft.

Console.Modes.UseAlternateWriteProc := False;

Du kannst das entweder direkt beim Start deines Programmes machen oder aber partiell bei einer Funktion, indem Du ihn auf False und danach wieder auf True stellst.

[Andreas13]

Hallo Wolfgang,
danke für den Hinweis. Leider funktionier es bei mir noch nicht ganz korrekt. Im Anhang ist ein kleines Demo dazu.

PrintVektor(..) ist eine "alte" (= bestehende) Routine, die System.WriteLn(..) verwendet.
Auch wenn ich Console.Modes.UseAlternateWriteProc := False; einstelle, wird der lange Output von PrintVektor(..) gekappt, weil System.WriteLn(..) nicht in Console. WriteLnConsole(..) umgeleitet wird, was ich mit meiner ursprünglichen Idee mit der "Zwischen-Unit" realisieren wollte.

[Andreas13]

Zitat von arcticwolf:

Zitat:

Weil es jedoch bei einer direkten Einbindung von Crt.pas zu Namenskonflikten kommt

Mit welchen Namenskonflikten hast Du zu kämpfen?

Habe gerade überprüft: Lediglich MaxX verursacht bei mir Probleme, weil dieser Bezeichner bereits in einer von mir anstelle von System.Math.pas benutzten Mathematik-Bibliothek verwendet wird.