Units unter uses weglassen

[RSE]

Ich habe gerade mal probiert, welche Units ich unter uses alles weglassen kann, ohne das der Compiler meckert. Erstaunlicherweise kann ich hier und da auch mal sowas wie Classes und Sysutils weglassen. Kann das zu Problemen führen, wenn ich solch substanzielle Units ausnehme, oder ist das generell kein Problem, wenn der Compiler das nicht anmeckert? Ich habe ein bisschen Bauchschmerzen wegen evtl. umdefinierten (betriebssystemrelevanten) Werten oder Typen und sowas. Was meint ihr dazu?

Grund des Experiments: Mir ist aufgefallen, dass sich jede Auskommentierung von ohnehin nicht benötigtem Quellcode (z.B. implementierte aber dann doch nie benutzte Klassen) positiv auf die Größe der resultierenden exe auswirkt.

[monta]

Naja, der Nutzen ist nur bedinegt, wenn du sie in anderen units trotzdem drin hast. Und was nicht benutzte Klassen angeht, wäre das Stichwort eigentlich Smartlinking.

Aber generell, du kannst solange rausschmeißen, wie der Kompiler es noch übersetzen kann. Übersetzt er es, läuft es später auch.

[theo]

Ich habe ein bisschen Bauchschmerzen wegen evtl. umdefinierten (betriebssystemrelevanten) Werten oder Typen und sowas. Was meint ihr dazu?

Die Units welche der Compiler zum compilieren nicht braucht, werden für das Programm nicht gebraucht. Wie auch? Späte kompilierung?

[monta]

Späte kompilierung?

Vielleicht hat sich doch ein NET-Jave-irgendwas-VM-Framework in den FPc eingeschlichen

[corpsman]

Ich schmeise die Units auch immer alle Raus, ebenfalls weils die Exe / binary klein hält.

Teilweise ist es auch sinnvoll zu schaun was man so aus einer Unit braucht.

Z.b. Sysutils unter Delphi 5

Eigentlich wurde die nur wegen inttostr eingebunden, machte die Exe aber um gut 112 kb größer.
=> inttostr selbst gemacht, unit nicht eingebunden, exe klein trotz inttostr

[RSE]

Wie auch? Späte kompilierung?

Nein, ich meinte Neudefinitionen von Datentypen. Also dass (primitives hypothetisches Beispiel) z.B. ein Cardinal standardmäßig mit 16Bit definiert ist und in der Unit "neueri386prozzi" auf 32Bit umdefiniert wird. Schmeißt man jetzt diese besagte Unit raus (welche in diesem Fall natürlich immer zuerst stehen müsste), hat man ein mächtiges Problem, das der Compiler aber nicht unbedingt bemerken muss. Vielleicht gibt es ja ein paar Konstanten oder sowas, welche in Classes redefiniert werden. Das war der Kern meiner Überlegungen.

@monta
Wie bekomme ich den Compiler dazu nach der Umstellung auf link smart (Register Linker) und smart linkable (register code) das auch anzuwenden? Muss ich dafür manuell alle Compilate (*.ppu, ggf auch *.o, vielleicht noch weitere) löschen, damit er sie neu erstellen muss? Wenn ich nur umstelle und Build all ausführe, dann ändert sich an der Größe nämlich nichts.

[theo]

Vielleicht hat sich doch ein NET-Jave-irgendwas-VM-Framework in den FPc eingeschlichen

Uhh, gruselig...

Also dass (primitives hypothetisches Beispiel) z.B. ein Cardinal standardmäßig mit 16Bit definiert ist und in der Unit "neueri386prozzi" auf 32Bit umdefiniert wird. Schmeißt man jetzt diese besagte Unit raus (welche in diesem Fall natürlich immer zuerst stehen müsste), hat man ein mächtiges Problem,

Meinst du, dass wenn du den Code weitergibst und der nachher auf anderen Plattformen kompiliert wird, dass dann was fehlen könnte?
Nun, das wäre wenigstens theoretisch denkbar (im Gegensatz zur ersten Annahme), ich glaube aber nicht, dass es vorkommt.

[RSE]

Nein, das meine ich nicht. Ich meine, dass eventuell bestimmte Standardstrukte (Typen, Konstanten, was-weiß-ich-was) in der Classes-Unit irgendwo mittels einer (z.B. betriebssystemspezifischen) includedatei umdefiniert werden, bevor sie in anderen Units in vielleicht selten benutztem Code benutzt werden und die Folgen einer fehlenden Umdefinierung erst bei Benutzung des entsprechenden Codes als Runtime-Error sichtbar werden. Dabei könnte es sich z.B. um Konstrukte für die Kommunikation mit dem Betriebssystem handeln. Da aber offensichtlich keiner von so etwas weiß, wird es etwas derartiges wohl nicht geben und ich kann alles aussortieren, was der Compiler nicht bemängelt.

[monta]

glaube ich nicht. Es dürfte nichts in einer anderen Unit umdefiniert werden. Wenn wird es wohl in der selben Unit definiert in der auch die Variable deklariert wurde, somit würde das ein kompilieren ohnehin verhindern ist meine Einschätzung.

Smartlinking ist unter Windows nach verschiedenen Quellen standardmäßig aktiviert. Daher auch (bei neuen Versionen) kein unterschied mehr. Interfaces werden allerdings dennoch eingelinkt, so dass trotz Smartlinking ein weglassen der Unit noch eine zusätzliche Ersparnis bringen kann.

[RSE]

D.h., der Unterschied, wenn ich meine ungenutzte Klasse auskommentiere, resultiert nur noch aus der Einbindung des Interfaces dieser Klasse. Ich werde sie trotzdem bis auf weiters auskommentiert lassen

Wozu werden die Interfaces noch benötigt, wenn sie sowieso nur noch leere (und damit unbenutzbare) Hüllen sind?

Wenn Smartlinking unter Windows standardmäßig aktiviert ist, dann sollten die entsprechenden Optionskästchen aber auch checked sein (und falls nicht abschaltbar grau). Ich will das jetzt nicht unbedingt gleich als Bug in Mantis eintragen, aber extrem sinnig wär es schon.

[monta]

Interface war nicht ganz genau...

Zum einen wird die Initalization und ggf. finalization immer verwendet, was ggf. das Interface nach sich zieht.

Zum anderen kann es auch passieren, das gar nichts raus fehlt, weil die Klasse RTTI-Informationen enthält, die ja zur Laufzeit unabhängig davon verfügbar sein müssen, ob sie im Code benutzt werden oder nicht. Also verdirbt RTTI auch wieder ein Stück weit das Smartlinking. Denn dann sind sie nicht nur Hüllen sondern ziehen den Rest der unit wieder mit rein.
Und RTTi beginnt standarmäßig bei TPersistent und wird mit vererbt. ({$M+})

[RSE]

Aso, das klingt sinnig. Das Rausschmeißen der Units hat auch nix gebracht. Offenbar ist das wiklich nur sinnvoll, wenn der Compiler einen drauf hinweist