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

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

[Sinspin]

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

Wieder was gelernt
Mir ist schon vor langer Zeit beim durchsuchen von meinen, mit Delphi erzeugten, Binaries aufgefallen das da die ganzen Unit Namen drinne stehen. Einen Sinn habe ich darin nie gesehen.
Ich verwende die Initialization Abschnitte auch nicht zum sammeln von Unit Namen, wozu auch . Sondern zum registrieren von Funktionen oder Klassen für automatische Konverter/etc.

[himitsu]

Jupp, diese Liste wird benutzt, um beim Start alle Initialization und am Ende alle Finalization zu durchlaufen.
Aber dort stehen nicht ALLE Units drin, vor allem nicht, wenn sie weder Initialization/Finalization, Class-Constructor/Destructor oder globale Variablen haben, weil dann ist es ja nicht nötig was zu machen.

Auch in den Ressourcen der EXE/DLL findet sich was, wo die Units aufgelistet werden.

Dann die Debuginfos als PE-Section.

Oder, wie schon gesagt, über TRTTI danach suchen.

[dummzeuch]

Zitat von Sinspin:

sammeln von Unit Namen, wozu auch .

Z.B. um im (generischen) About-Dialog die passenden Credits zu den verwendeten Bibliotheken anzuzeigen. Dazu ist das echt praktisch.

[himitsu]

Du baust also extra einen Code, der speziell nach dieser Unit sucht (oder Irgendeiner, die zufällig gleich heißt, aber was ganz Anderes ist),
um mit dieser Info dann was zu machen.

Warum dann nicht diese Info direkt reinschreiben?


Wenn, dann wäre es besser, wenn der Entwickler eine standardisierte Credits-Ressource bei legt, oder z.B. ein standardisiertes Credits-Attribut an seine Unit/Klasse/Sonstwas hängt, die man dann leicht finden könnte.

[dummzeuch]

Zitat von himitsu:

Du baust also extra einen Code, der speziell nach dieser Unit sucht (oder Irgendeiner, die zufällig gleich heißt, aber was ganz Anderes ist),
um mit dieser Info dann was zu machen.

Warum dann nicht diese Info direkt reinschreiben?

Wenn, dann wäre es besser, wenn der Entwickler eine standardisierte Credits-Ressource bei legt, oder z.B. ein standardisiertes Credits-Attribut an seine Unit/Klasse/Sonstwas hängt, die man dann leicht finden könnte.

Ich vermute, zumindest der letze Absatz bezog sich auf mich?

(Hint: Ein Quote hätte hier Klarheit geschaffen.)

Da die Entwickler diese Ressource nicht zur Verfügung stellen und ich nicht an deren Code rumfummeln will, war die Suche nach einer Unit, die beim Einbinden einer Bibliothek immer vorhanden ist, die einfachste Lösung. Und da die meisten Bibliotheken ein individuelles Prefix im Unit-Namen verwenden, ist das auch ziemlich eindeutig.

[himitsu]

Das bezog sich eigentlich auf "alle" Entwickler von Komponenten


Und wie schon erwähnt, kannst'e bei vielen Komponenten auch nach einer derer Ressourcen suchen.

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