Uses Liste

[Goldor]

Ich wollt euch mal fragen, ob ungebrauchte Uses in der
usesliste zu programmproblemen führen können? ich will
nämlich mal eine sammlung von uses aufstellen und wollte
wissen ob zu viel des guten probleme macht. wär cool wenn
ihr ein paar kennen würdet und die hier posten könntet.
thx

[geskill]

Dadurch wird die Anwendung größer, dass ist ein sehr guter Grund warum viele Programmierer diese immer sehr schlank halten ;)
Aber schaden kann es im dem Sinne nicht.

[Tyrael Y.]

Ich verstehe den Sinn nicht.

was ich nicht in der Unit brauche gehört da auch nicht rein.

[Goldor]

ich werd da ja auch nicht unsinniges zeug reinbauen aber
ich will mir ein programm zum schnellen ''bauen'' einer unit
programmieren und will dann dort die uses elemente als check-
boxen einfügen lassen können und brauch deshalb mal ein paar
mit erklärung

[geskill]

Wenn du die Elemente von der Tool-Box direkt per Drag & Drop auf das Formular ziehst werden diese doch automatisch ergänzt, gut ShellAPI, Math etc. muss man dann noch selber hinzufügen...
Aber da extra ein Programm für zu schreiben ... fände ich eher Zeitaufwendiger so ein Programm vorher zu starten... aber was habe ich nicht alles zum begin programmiert ^^

[Meflin]

Zitat von Goldor:

Ich wollt euch mal fragen, ob ungebrauchte Uses in der usesliste zu programmproblemen führen können?

Definitiv: Ja! Es können dadurch ganz nette Namenskonflikte entstehen, zum Beispiel mit Windows.Bitmap und Graphics.Bitmap - da sucht man schon mal ein bisschen länger nach dem Fehler

[mjustin]

Zitat von Goldor:

Ich wollt euch mal fragen, ob ungebrauchte Uses in der
usesliste zu programmproblemen führen können? ich will
nämlich mal eine sammlung von uses aufstellen und wollte
wissen ob zu viel des guten probleme macht. wär cool wenn
ihr ein paar kennen würdet und die hier posten könntet.
thx

• Gefahr zirkulärer Referenzen nimmt zu
• Compiler wird mit zunehmender Anzahl Units spürbar langsamer
• Analyse von Unit-Abhängigkeiten wird zeitraubender

Bei sehr grossen Projekten ab ca. 1 Mio Zeilen lohnt sich das regelmäßige Aufräumen

[Cyf]

Hmm, über die exakten folgen hab ich auch neulich mal nachgedacht.
Also auf jedenfall sollte ja folgendes der Fall sein:

- Es werden unnötige globale Variablen angelegt.
- Nicht benutzte Ressourcen werden mit einkompiliert.
- Unnötige initialization- und finalization-Abschnitte werden ausgeführt.
- Namenskonflikte
- generell weniger Übersicht und Überblick über Abhängigkeiten

Das sollte soweit richtig sein oder?
Aber wie sieht das z.B. mit Code von Objekten, die man garnicht benutzt aus? Erkennt das der Compiler und lässt ihn außen vor, oder wird die Exe unnötig mit Code aufgebläht, der nie zum Einsatz kommt?
Bei Java z.B. wird ja für jede Klasse grundsätzlich eine eigene Unit angelegt, hat das nur gründe der Übersichtlichkeit oder auch wegen sowas.
Sprich, macht es Sinn Units von denen man manche Klassen nur selten benötigt, nochmals zusätzlich zu splitten, auch wenn diese thematisch zusammen gehören?

[sirius]

Zitat von Cyf:

Aber wie sieht das z.B. mit Code von Objekten, die man garnicht benutzt aus? Erkennt das der Compiler und lässt ihn außen vor, oder wird die Exe unnötig mit Code aufgebläht, der nie zum Einsatz kommt?

Meiner Beobachtung nach werden sogar ungenutzte Methode nicht mit in daa Final gelinkt. Das trifft natürlich dann auch für vollständige Objekte zu. Compiliert für die dcu werden sie höchstwahrscheinlich.

[Cyf]

Hab soweit das selbe beobachtet, da sich die Exen nicht vergrößern, wenn man eine selbstgeschriebene Unit mit beliebig vielen unbenutzten Funktionen (auch außerhalb von Klassen) linkt. Nur für benutzte scheint die Größe tatsächlich zuzunehmen. Wie das mit den Klassen selbst aussieht, hab ich jetzt nicht probiert, aber wird wahrscheinlich genauso sein, wenns bei Funktionen funktioniert. In den .dcu sollten sie jedoch auf jeden Fall vorhanden sein, sonst könnte man diese ja nicht aus dem Projekt entfernen und andereorts verwenden.