Allgemeine Fragen zu Dlls

[Vodo Breath]

Wenn ich eine Dll erstelle und die lib einbinde (auch die header) kann ich funktionen, enums, klassen... in die dll packen ->schon gelernt wie das geht

nu meine fragen:

1 Wenn ich eine Funktion aufrufe (aus der dll) wird die jedesmal aus der dll genommen oder am anfang geladen?

2 Bringt es Geschwindigkeitsverluste Funktionen oder enums in eine dll zu packen?

[audacia]

Vodo Breath schrieb:

1 Wenn ich eine Funktion aufrufe (aus der dll) wird die jedesmal aus der dll genommen oder am anfang geladen?

Der Code wird in den Arbeitsspeicher geladen, wenn du die DLL lädst (Optimierungen wie Lazy Evaluation, die der Kernel hier vornehmen könnte, außen vor gelassen), bzw. vor der Ausführung der Anwendung, wenn die DLL statisch eingebunden ist.

Vodo Breath schrieb:

2 Bringt es Geschwindigkeitsverluste Funktionen oder enums in eine dll zu packen?

Ein enum ist lediglich eine Typdeklaration, die in einer Headerdatei steht; dafür wird kein Code generiert.

Die Geschwindigkeit des Aufrufes einer Funktion hängt davon ab, welchen Typs sie ist. Bei Aufrufen statisch gelinkter Funktionen fügt der Linker deren Sprungadresse direkt in den Code ein; diese werden am schnellsten aufgerufen. Funktionen aus dynamisch geladenen DLLs werden über Funktionszeiger angesprochen, was etwas langsamer ist, und für statisch eingebundene DLLs generiert der Compiler für jede importierte Funktion einen Stub, in welchem vom Kernel beim Laden der Datei die Funktionsadressen eingetragen werden, es sind also zwei quasi hartcodierte Jumps notwendig. Inwiefern sich das in der Geschwindigkeit von den anderen Aufrufarten unterscheidet, müßte man mittels eines Profilers herausfinden, jedoch ist der Effekt vermutlich sehr gering - wenn er nicht in den durch das Caching verursachten Geschwindigkeitsunterschieden untergeht.

[this-*gt*that]

Es gibt keine statisch gebundenen DLLs

[tenchou]

bla er meint implicit runtime linking

[this-*gt*that]

tenchou schrieb:

bla er meint implicit runtime linking

Soll das ein Fachbegriff sein?

[tenchou]

jo hab ich aus wikipedia

[hustbaer]

Er meint bei statisch eingebundenen Funktionen eben, also OHNE DLL.

[tenchou]

ne dann hätte er ja nicht DLL gesagt. er meinte

1.statisch gelinkt
2.dll die mit lib benutzt wird und geladen wird bevor die programmausführung beginnt
3.dll die explizit mit loadlib geladen wird

[audacia]

tenchou schrieb:

er meinte

1.statisch gelinkt
2.dll die mit lib benutzt wird und geladen wird bevor die programmausführung beginnt
3.dll die explizit mit loadlib geladen wird

So ist es.

Warum man Fall 2 nicht "statisch eingebundene DLLs" nennen sollte, erschließt sich mir nicht.

[hustbaer]

.

[this-*gt*that]

audacia schrieb:

tenchou schrieb:

er meinte

1.statisch gelinkt
2.dll die mit lib benutzt wird und geladen wird bevor die programmausführung beginnt
3.dll die explizit mit loadlib geladen wird

So ist es.

Warum man Fall 2 nicht "statisch eingebundene DLLs" nennen sollte, erschließt sich mir nicht.

Weil eine STATISCHE Einbindung einer DYNAMISCHEN Link Library sinnfrei ist. Statische Bindung bedeutet, dass beim Linken der Objektcode in das Binary aufgenommen wird. Und genau das wird eben bei DLLs nicht gemacht - völlig egal ob implizit oder explizite Einbindung.

[Unix-Tom]

Aber Vorsicht. Soll der Programmcode der DLL nur einmal im Speicher vorliegen dann muss immer die gleiche DLL aufgerufen werden. Windows Unterscheidet auch hier in welchem Verzeichnis sich diese befindet. 2 Aufrufe mit Unterschiedlichen Verz. laden auch den selben Code 2 Mal in den Speicher was eigentlich nicht der Sinn einer DLL ist.

[audacia]

this->that schrieb:

Weil eine STATISCHE Einbindung einer DYNAMISCHEN Link Library sinnfrei ist.

Aus Sicht des Programmierers ist es eine teils vom Linker, teils vom PE-Loader vorgenommene statische Einbindung, da der Code weder manuell (dynamisch) geladen werden muß noch kann. Der Begriff "statisches Einbinden einer DLL" gibt diesen Sachverhalt IMHO unzweideutig wieder - DLLs können nur zur Laufzeit geladen, aber statisch eingebunden werden.

[this-*gt*that]

Wie gesagt: statisch ist zur Compile/Linkzeit, dynamisch zur Laufzeit. Die Begriffe sind eigentlich gut definiert...
Aber es sei dir freigestellt weiter deine Terminologie zu benutzen;)

[RHBaum]

Weil eine STATISCHE Einbindung einer DYNAMISCHEN Link Library sinnfrei ist.

Nicht ganz ! oder hasst du ne andere Idee um nen funktionalitaet aus nem compilierten binary das ne andere runtime nutzt, in deiner App zu verwenden ?

Dll's sind unter anderem auch gut, wenn man projekte entkoppeln will. also teilaufgaben einem anderen Team / firma zuweissen will die ne andere runtime / anderen compiler verwenden.

klar kann man die nicht mit der vom dll compiler generierten importlib linken lassen, aber vielleicht kann man die importlib vom eigenen compiler bauen lassen.

oder die lib selber proggen ...

Ciao ...

[audacia]

this->that schrieb:

Wie gesagt: statisch ist zur Compile/Linkzeit, dynamisch zur Laufzeit. Die Begriffe sind eigentlich gut definiert...

Das steht nicht im Widerspruch zum Begriff der statisch eingebundenen DLL. Für die formelle Einbindung sorgen ja Compiler und Linker, lediglich das Laden der Datei erledigt das Betriebssystem. Das Laden der DLL geschieht überdies auch nicht zur Laufzeit, sondern kurz davor, nämlich wenn der PE-Loader die Anwendung initialisiert.

Abschließend sollte ich vielleicht auf den entsprechenden MSDN-Artikel verweisen:

MSDN - Linking an Executable to a DLL schrieb:

Implicit linking is sometimes referred to as static load or load-time dynamic linking.

Demnach können wir uns auf den weniger explanativen, aber offenbar gemeinhin gebräuchlichen Begriff "implizites Linken" einigen