spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Höchstens so langsam wie ein einfacher Virtual Function Call...

Eine Vektor-Addition für einzelne Vektoren würde man daher lieber nicht in eine DLL packen.

Ich hab mich bei dem Thema ja schon oft aus dem Fenster gehängt, aber ich tu's gern nochmal :-)

Vorteile:
- Code unabhängig austauschbar, sofern jedes Detail der Schnittstelle exakt gleich bleibt
- coole Möglichkeiten für Plugins und dynamische Code-Einbettung

Nachteile:
- getrennter Heap und viele potentielle Konflikte mit der CRT, Klassen usw.
- jeder Aufruf kostet mehr Zeit als eine normale Funktion
- kein Inlining und keine globale Optimierung möglich
- DLL enthält immer alle Funktionalität, egal was der DLL-Nutzer eigentlich braucht

Meiner Meinung nach sind DLLs wirklich nur für die seltenen Fälle gut, bei denen man Code dynamisch laden will, den Code also zur Laufzeit noch nicht kennt. Und natürlich bei den Fällen, bei denen man schlicht keine Wahl hat. Für alles andere würde ich statisches Linken empfehlen. Schneller, kleiner, weniger Gerümpel.

Ich stimmt dir bei allem was du gesagt hast zu, einen ganz wesentlichen Punkt hast du aber vergessen: Verschiedenste Anwendungen können den Code sharen. Wenn jede .exe Dinge wie z.B. die WinAPI statisch linken würde, dann gute Nacht...

Zitat von »Evrey«

Ist halt die Frage, welche Art von Code man wie auslagern will. Wie David schrieb ist es Quatsch, eine simple Vector3D-Klasse oder sowas in eine DLL zu packen. Das wird nur langsam. Seltenere Funktionsaufrufe, und da zähle ich mal das WinAPI dazu, oder riesige/zeitintensive Funktionen wie das Packen eines Ordners mit 7Zip, können getrost in DLLs geballert werden. Wenn's schnell gehen muss: Statisch linken. Wenn's noch schneller/einfacher gehen muss: Header-Only-Bibliothek.

Zitat von »Evrey«

Natürlich hängt das vom Prozessor und Betriebssystem ab, aber wenn wir berücksichtigen, dass wir das Jahr 2012 schreiben und Dinge wie z.B. Waschmaschinen ausschließen, dann implementiert das Betriebssystem Virtual Memory auf Basis von Paging und die Addressumrechnung ist ein Overhead der da ist, wann immer irgendwo auf Speicher zugegriffen wird und wird z.B. von der MMU des Prozessors völlig transparent in Hardware erledigt. In jedem Fall wird eine dll in den Addressraum des jeweiligen Prozesses gemapped, anders würde das alles gar nicht funktionieren...

Zusätzlicher Overhead gegenüber einem direkten, normalen Function Call entsteht lediglich aus der Tatsache, dass die Funktion dynamisch gebunden wird und daher über einen Zeiger aufgerufen werden muss. Unter Windows funktioniert das so, dass deine Binary eine sog. Import Address Table hat, die Zeiger auf Funktionen und Variablen, die aus einer dll importiert werden sollen enthält. Die Binary realisiert alle Aufrufe bzw. Zugriff dann über diese Zeiger und das Betriebbssystem mapped beim Laden alle benötigten dlls in den Addressraum des neuen Prozesses und füllt die Tabelle aus.

Zitat von »MazzMan«

Würdet ihr z.B. GUI-Elemente in eine DLL machen?

Auch welchen Gründen genau möchtest du das in eine dll packen?

Zitat von »MazzMan«

Außerdem wurde hier auch schon der Konflikt mit Klassen genannt. Da wäre auch meine Frage, ob es möglich ist eine Klasse einfach zu Exportieren, oder ob das komplizierter ist, als mit Funktionen.

Rein prinzipiell kann eine dll nur Funktionen und Variablen exportieren. Alles weitere geht lediglich über compilerspezifische Spracherweiterungen wie z.B. dllexport von MSVC und ist nicht unproblematisch. Rein prinzipiell funktioniert es damit zwar relativ einfach, aber man muss eben aufpassen was man tut. Ein beliebter Fallstrick ist z.B., dass Leute gleich mal Dinge wie z.B. einen std::string an eine Funktion in einer dll übergeben, was nur unter ganz bestimmten Voraussetzungen nicht dazu führt, dass gleich alles in die Luft fliegt. Abgesehen davon bin ich persönlich der Meinung, dass dllexport für Klassen rein prinzipiell den Sinn von dlls untergräbt.

Aus aktuellem Kontext:

Ich verwende für mein Spiel zB DLLs, damit Spieler eigene Sektortypen importieren können. Ich kann ja nicht für jeden Sektor, den jemand aus der Community entwickelt, eine neue Build des Spiels erzeugen und rausbringen. Also kann ein Spieler eine DLL erzeugen, die den Code zur Erzeugung des Sektors enthält. Die implementiert dann eine mit dem Spiel gemeinsame Schnittstelle, die ebenfalls wieder in einer DLL vorliegt. Diese DLL enthält dann auch noch ein paar userdefinierte Objekte, die in der Schnittstelle verwendet werden.
Auf diese Weise kann ein Spieler einfach eine DLL erzeugen, in den Ordner des Spiels stecken und schon kann das Spiel auf den darin definierten Sektor zugreifen, ohne, dass ich am Spiel selbst irgendetwas verändern muss. Der Vorteil dürfte relativ klar sein

Ein weiteres Beispiel aus meinem aktuellen beruflichen Projekt:
Der Kunde wünscht eine rein plugin-basierte Software, sprich eine .exe, die immer gleich ist (und nur das Basisfenster mit Statusleiste, TreeView, und Menü enthält) und dann werden nur noch zusätzliche DLLs ausgerollt, um neue Plugins automatisch in die Software zu integrieren, ohne die .exe anfassen zu müssen. Dieses DLLs enthalten dann sowohl Benutzeroberflächen (User Controls) als auch den entsprechenden Code.

Ich verwende beides. Aber ich verweise noch auf einen Punkt, der bisher nicht genannt wurde, nämlich den Begriff "DLL-Hell". Und den gibts nicht umsonst. Wenn man mal ein Rudel an DLLs zusammen hat, dann kann das ganz schön nervig werden, vorallem wenn versch. Anwendungen gleiche Abhängigkeiten mit unterschiedlichen Versionen haben. Beispiel hierzu Qt: Ich habe hier ständig Konflikte weil Tools wie Tortoise<SCM-hier> ihre Qt-DLLs über die Pfad-Umgebungsvariable im ganzen System bekannt machen. Das kollidiert dann mit Release-Builds der eigenen Projekte, weil die je nachdem die Qt-DLL von Tortoise zuerst finden. Ganz schlimm wird das bei DLLs wenn man mal mit .NET, Managed C++ Wrapper und Native C++ DLLs gearbeitet hat.