Vorgeschichte:

Im Rahmen der Optimierung eines meiner Projekte hat mir ein Programm (ICARUS) gezeigt, welche Units in den USES auftauchen müssen und welche überflüssig sind. Dabei zeigt das Programm auch, welche Units vom Uses im Interface nach dem Uses im Implementation-Teil verschoben werden kann.

Ich weiß, dass Uses im Implementation-Teil oft dazu nötig ist, um mögliche Cross-Referenzen zu vermeiden. Aber dies ist ja bei Systemunits nicht zu erwarten.

Daher die Frage:

Welchen Vorteil bietet eine Einbindung einer Systemunit (z.B. Windows) im Implenentation-Teil gegenüber dem Interface-Teil? Oder gibt es da eh keinen Unterschied?

(Info, ich habe Delphi 5 Professionell)

Tranx hat folgendes geschrieben :

Welchen Vorteil bietet eine Einbindung einer Systemunit (z.B. Windows) im Implementation-Teil gegenüber dem Interface-Teil? Oder gibt es da eh keinen Unterschied?

In windows.pas werden einige Dinge definiert. Verwendest Du diese im Interface-Teil, dann muß auch windows oben unter uses aufgeführt sein.

Beispiel:



Mit windows im Implementation-Teil wirst Du das nicht kompilieren können.

Deshalb würde ich die von Delphi im Interface-Teil aufgeführten Units auch da stehen lassen. Eine "Optimierung" ist das sicherlich nicht, wenn man bei jedem neuen Projekt oder bei jeder Änderung im Interface-Teil entscheiden muß, ob das nun unter Implementation oder Interface hingehört.

Hallo Tranx,

Tranx hat folgendes geschrieben :

Welchen Vorteil bietet eine Einbindung einer Systemunit (z.B. Windows) im Implenentation-Teil gegenüber dem Interface-Teil? Oder gibt es da eh keinen Unterschied?

Ich finde diese Frage auch sehr interessant.

Im Netz habe ich unter www.delphibasics.co.uk/RTL.asp?Name=Uses gefunden:

Zitat:

For Units, the Uses may be defined in the Interface and Implementation sections. It is cleaner and may save recompilations if you put units used in the implementation section if they are only used there.

verstehe es aber nicht. Worin besteht der Vorteil? Wieso werden Units im Implementation-Teil "sicherer" compiliert?

Ich habe spaßeshalber in einigen Projekten einige Units aus dem Interface-Teil in den Implementation-Teil verschoben.
Im Ergebnis wurde die Exe jeweils um einige Bytes größer. Warum?

Beste Grüße
Mathematiker

Zitat von Mike Sutton aus diesem Thread:

Zitat:

The IDE also uses how where you declare your uses to ascertain what it needs to compile. If your interface section uses UnitA and your implementation section uses UnitB then, if unit B needs recompiling, your unit won't, but if unitA changes then your unit will need to be recompiled. It's one of the secrets of Delphis super fast build speed. As to your finished executable, I expect that it will turn out the same size wherever you put the declarations (the linker is clever and only links in methods etc that are actually used by your application), but the actual location of various sources would almost certainly change if the order of the unit declarations is changed.

BTW: nicht "sicherer kompilieren", sondern "spart Kompilieren ein"

WasWeißDennIch hat folgendes geschrieben :

BTW: nicht "sicherer kompilieren", sondern "spart Kompilieren ein"

Richtig! Mein Fehler.
Allerdings frage ich mich, was es bringt. Nach meinem Verständnis werden Units doch nur dann neu compiliert, wenn sich ihr Inhalt ändert oder wenn ich z.B. über "Alle Projekte compilieren" usw. es extra aufrufe. Sehr merkwürdig.

Beste Grüße
Mathematiker

Naja, dann belasse ich sicherheitshalber die Systemunits im Interfaceteil.

Habe in dem Zusammenhang - Euch wird das sicher ein alter Hut sein - weil ich ja die Uses bereinigen wollte, die IDE-Erweiterung CNPack gefunden. Das ist wirklic heine sehr sinnvolle Sache. Und selbst für meine alte Delphi-Version noch fast voll nutzbar. Da sieht man z.B. die Begin-End-Zusammenhänge im Quelltext (durch senkrechte Linien und verschiedene Färbungen von begin-end. Das ist insbesondere bei verschachtelten und über mehrere Zeilen gehende begin-end sehr gut. Auch die Klammern werden automatisch zugeordnet (Verfärbung im Quelltext). Und einige IDE-Erweiterungen wie Bereinigung, automatische Variablenergänzung, Korrekturen über mehrere Dateien .... Schaut Euch das mal an (Wird in die IDE nach Setup eingebaut. Bei mir kommt eine Fehlermeldung, dass meine IDE veraltet sei, habe ich weggeklickt, weiß ich!)

Link:

www.cnpack.org/showd...p?id=727&lang=en

WasWeißDennIch hat folgendes geschrieben :

BTW: nicht "sicherer kompilieren", sondern "spart Kompilieren ein"

Einer der Gründe, warum ich Angelsächsisch so "liebe": Seine "Exaktheit", insbesondere für Nichtmuttersprachler, aber auch für Muttersprachler.

Die Größe der Compilate wird jedenfalls davon, wo die uses-Anweisung sich befindet, in der die Units hingepackt werden, höchstwahrscheinlich nicht beeinflußt.

Tendenziell kann man aber alles so weit wie möglich "internalisieren" bzw. verstecken (von interface nach implementation, von global zu lokal (möglichst tief in die Schachtelungen) u.ä.), solang der Compiler sich nicht beschwert, das vermindert die Gefahr unerwünschter Seiteneffekte, die manchmal schwierig zu findende Fehler verursachen.

Allerdings sollte man in dem, was Delphi automatisch vorgibt, nicht grundlos "rummachen".

Mehrdeutigkeit gibt es auch in anderen Sprachen, auch im Deutschen. Außerdem besteht ja ein Unterschied zwischen "save" und "safe", gell? Zum Thema: ich persönlich habe mir angewöhnt, "Hilfsunits" im implementation-Abschnitt einzubinden. Das funktioniert natürlich nur solange, wie im interface-Abschnitt nichts steht, was bereits auf eine dieser Units zugreift. Aber wie im verlinkten Thread jemand sagte: das soll jeder halten, wie er es für richtig hält, und so sehe ich das auch.

Wenn man eine Unit eingebunden hat, muss die eigene Unit ggf. neu kompiliert werden, wenn die andere sich ändert. Solange sich aber nur etwas geändert hat, das sich im nicht nach außen sichtbaren Teil befindet (in der implementation Sektion), ist dies aber nicht notwendig. Nur, wenn sich etwas in der Schnittstelle zu anderen Units (der interface Sektion) geändert hat, muss die eigene Unit neu kompiliert werden, da sich für diese potentiell etwas geändert hat.

Das gilt natürlich auch für Änderungen in in der interface Sektion eingebundenen Units, da z.B. Datentypen aus diesen Units wiederum indirekt in der eigenen benutzt worden sein könnten.

Deshalb kann das Vorgehen, alles nach implementation zu verschieben, die Kompilierzeit herabsetzen. Man erkauft sich das damit, dass man z.B. Kreuzbezüge nur durch eigene Analyse des Quelltextes bemerkt und die Übersicht IMHO ein wenig leidet.

WasWeißDennIch hat folgendes geschrieben :

Mehrdeutigkeit gibt es auch in anderen Sprachen, auch im Deutschen.

Tendenziell ist das Deutsche aber exakter. Wir haben z.B. einen Konjunktiv I....

So, ich probierte das eben mal aus. Delphi fügt automatisch etliche fehlende Units im Interface hinzu, so z.B. in einem Programm, das Stringgrid verwendet: Windows, Menus, Classes, Controls, Grids - ein Verhalten, daß Ihr auch sicher schon beobachtetet. Merkwürdigerweise nicht die Unit Forms, die wird vermißt (das Stringgrid ist allerdings auf ein Formular "gebebberlt"). Im Implementation-Teil können dann solch "unwichtige" Units wie SysUtils, Graphics und Dialogs erstmalig genannt werden.

Ich schrieb weiter oben, daß man nicht unnötig an den von Delphi vorgegebenen Quelltexten "rummachen" sollte. Das muß ich relativieren: Ich entferne generell alle unnötigen Units.