globale Unit mit Konstanten o.ä. sinnvoll?

[r2c2]

Zitat von p80286:

aber nichts anderes habe ich aus den vorhergehenden Beiträgen entnommen.
Konstanten (und/oder ..), die zu einem Thema gehören, werden in einer (Themen-Zentral-Unit) zusammengefasst.

und zwar zusammen mit den Funktionen, Klassen, etc. und nicht getrennt davon. So gruppiert, wie man sie wiederverwenden würde. Himitsu hat ein schönes Beispiel geliefert... nachträglich in seinen Post oben reineditiert. Als ich gepostet hatte, stand das noch nicht drin. Ich wollte das nur klar machen. Zu der Zeit als ich gepostet hatte, war das noch nicht so klar in diesem Thread. Und TypeDefs.pas und Consts.pas sind leider weit verbreitet.

Ich sehe also nicht, wo wir uns widersprechen.

mfg

Christian

[Bernhard Geyer]

Zitat von r2c2:

und zwar zusammen mit den Funktionen, Klassen, etc. und nicht getrennt davon.

Doch getrennt. Hatte schon öfters denn Fall das ich zwar die Konstanten benötigt habe (Für Supporttools die nur einfache Checks durchführen) aber nicht die entsprechenden Klassen.
Hätte ich alles in einer Unit wäre mein einfaches Support-Tool mehrere MB größer und würde einige andere DLL's zur laufzeit benötigen da diese (für diese Anwendungszweck) unnötigen Abhängigkeiten in die Exe kompiliert werden.

[himitsu]

Wenn die Klassen nicht verwendet werden, dann wird ihr Code auch nicht in die EXE/DLL/BPL einkompiliert.

Es macht diesbezüglich also keinen Unterschied, ob die Klassen in der Unit liegen oder nicht.

OK, man sollte nicht, so wie in SysUtils oder Classes alles in Initialization initialisieren, denn dann wird es dennoch eingebunden, da es ja in Initialization verwendet wird.
Dafür gibt es seit einer Weile das class constructor Create; , welches nur eingebunden und wie das Initialization aufgerufen wird, wenn die Klasse wirklich verwendet wurde.

[Bernhard Geyer]

Zitat von himitsu:

Wenn die Klassen nicht verwendet werden, dann wird ihr Code auch nicht in die EXE/DLL/BPL einkompiliert.

Es macht diesbezüglich also keinen Unterschied, ob die Klassen in der Unit liegen oder nicht.

Die entsprechenden Units haben initialization/finalization-Code + Feste einbindung von DLL's + Ressourcenabschnitte.

Zitat von himitsu:

OK, man sollte nicht, so wie in SysUtils oder Classes alles in Initialization initialisieren, denn dann wird es dennoch eingebunden, da es ja in Initialization verwendet wird.

Und wenn du entsprechen anzahl von Elementen hast die zu 99% bei normalen Apps benötigt werden und zu 100% bei VCl-Form-Apps? Dann jedesmal dem Entwicker nahe legen noch x Initialization-Funktion aufzurufen? Ok, es gibt mittlerweile genügen Pattern wie man sowas besser macht, aber wieviel Stunden würde das benötigen um einen XE2-Code um solche seit Delphi 1/2 vorhandenen Codeteile fehlerfrei umzustellen. Application.Initialize und Application.MainFormVisible (?) haben schon für genügend Threads hier im Forum geführt.

[r2c2]

Ich glaube wir haben hier eine Form von ViolentAgreement. Mein Punkt war nur, dass man Konstanten nicht deshalb trennen soll, weil es Konstanten sind. Wenn man die Konstanten sinnvollerweise getrennt verwenden kann, kann und sollte man tatsächlich überlegen, ob man das in ne separate Unit packt. Eine Unit ist in Delphi die Einheit für die Wiederverwendung. Man sollte alles so in Units gruppieren, wie man es wiederverwenden würde.

Es gibt dabei einen Graubereich, in dem man abwägen kann, ob man jetzt in nem bestimmten Fall das besser trennt oder zusammen lässt. Was jetzt wie mit einkompiliert wird (himitsu hat da nen wichtigen Punkt erwähnt) kann bei der Überlegung ne Rolle spielen. Auf der anderen Seite spielen auch Lesbarkeit und Übersicht ne Rolle (zu lange Units sind unübersichtlich, zu viele Units sind unübersichtlich, zu viel Code, der nicht verwendet wird ist unübersichtlich). Man muss eben nen Mittelweg finden.

Also ich sage nicht, dass man auf Teufel komm raus Konstanten und Klassen zusammen lassen soll und du hast auch nie gemeint, dass man Konstanten immer in ne eigene Unit packt, egal obs Sinn macht oder nicht. Essentiell vertreten wir die selbe Position. ==> ViolentAgreement. Wir sollten uns nicht drüber streiten.

mfg

Christian

[Bernhard Geyer]

Zitat von r2c2:

ViolentAgreement. Wir sollten uns nicht drüber streiten.

Ach meno. Jetzt wo ich in Fahrt komme. Musst du jetzt auf Geißler machen

Du hast es gut ausgedrückt.

[himitsu]

Ich glaub das hast du nicht ganz richtig verstanden.

Die Klassenkonstruktoren werden automatisch aufgerufen,
aber im Gegensatz zum Initialization-Abschnitt wird die Klasse nur eingebunden wenn sie verwendet wird und ihre Initialization (class constructor) wird nur aufgerufen, wenn die Klasse eingebunden wurde.

Macht man das in dem Initialization-Abschnitt, dann wird schon alleine durch die Initialization die Klasse eingebunden, egal ob sie wo anders noch verwendet wird.

Leider gibt es sowas nicht für die Resourcen {$R ...} , welche immer gelinkt werden, egal ob sie nötig sind.
Wäre schön, wenn man diese auch irgendwo dranbinden könnte.