Vor- und Nachteile der Verwendung von DLLs [geschlossen]

Ich frage mich, ob ich jedes Game-Engine-Modul (Rendering, Eingabe, Sound usw.) in DLLs (renderer.dll, input.dll usw.) erstellen soll. Was sind Ihrer Meinung nach Vor- und Nachteile einer Aufteilung des Spiels in DLLs? Ich sehe nur die Notwendigkeit, das Spielmodul in eine separate DLL zu schreiben, um die Möglichkeit zu haben, Mods zu erstellen.

Vorteile

• Sie können DLLs separat erstellen.
• Es könnte schneller sein, eine DLL neu zu erstellen

Nachteile

• Das Aufrufen von Code aus der DLL ist langsamer
• Es wäre langsamer, ein Lochprojekt mit allen DLLs neu zu erstellen
• Funktionsnamen sind sichtbar. Es ist einfacher, Code umzukehren, der dynamische DLLs verwendet

Ich sehe keinen Sinn darin, render.dll und input.dll zu haben. Aber einige RareUsedJoystick.DLL könnten als ladbares Modul erstellt werden, um Speicher für diejenigen freizugeben, die diesen RareUsedJoystick nicht verwenden

Das Einfügen von Code in separate Windows-DLLs klingt theoretisch vielversprechend, in der Praxis sollten Sie sich jedoch bestimmter Einschränkungen bewusst sein.

1. Sie müssen alle Ihre Klassen und globalen Funktionen, die Sie von außen verwenden möchten, als "exportierbar" deklarieren

   __declspec( dllexport ) class Foo {};

   beim Aufbau der Bibliothek. Clients Ihrer DLL müssen das Include wie folgt "sehen":

   __declspec( dllimport ) class Foo {};

   Aus diesem Grund sehen Sie ein Makro vor Klassendeklarationen in DLL-Headern.

2. Ressourcen wie FILE * -Zeiger können nicht unter allen Umständen (verschiedene CRTs) zwischen DLLs gemeinsam genutzt werden. Das heißt, wenn Sie die Datei in einer DLL öffnen, können Sie weder über die Client-App oder eine andere DLL darauf schreiben noch sie schließen.

   http://msdn.microsoft.com/en-us/library/ms235460%28VS.80%29.aspx

3. Speicherverwaltung: Sie können unter allen Umständen keinen Speicher in der DLL zuweisen und in einer anderen DLL oder in einer Clientanwendung freigeben (unterschiedliche CRTs).

4. Das Exportieren von Vorlagenklassen kann sehr schmerzhaft sein, insbesondere wenn statische Elementvariablen verwendet werden.

Wenn Sie Ihren Code nur wiederverwenden möchten, ohne ihn neu zu kompilieren, gibt es eine andere Option, statische Bibliotheken (.lib). Es handelt sich um vorkompilierten Code (wie in der DLL), der jedoch mit Ihrer Anwendung verknüpft ist und keine der oben genannten Einschränkungen aufweist. Außerdem funktioniert die Generierung des Link-Zeitcodes weiterhin mit dem Bibliothekscode.

Update: Wie Sean in den Kommentaren hervorhob, können Punkt 2 und 3 funktionieren, wenn dieselbe CRT-Version verwendet wird, wie auch der MSDN-Link in 2 zeigt. Mein Rat ist jedoch, die DLL zu entwerfen, ohne sich darauf zu verlassen, da es so viele Fälle gibt, in denen sie nicht funktioniert, z. B. die Verwendung von 2 DLLs mit unterschiedlichen CRTs oder die Kompilierung mit unterschiedlichen Visual Studio-Versionen.

Die meisten Unterschiede sind vernachlässigbar. DLLs sind flexibler, machen den Erstellungsprozess jedoch komplexer. Ich würde DLLs nur verwenden, wenn:

• Mehrere Anwendungen müssen auf dieselbe Funktionalität zugreifen. Zum Beispiel, wenn Sie separate Binärdateien für einen Editor und das Spiel selbst haben.
• Sie möchten, dass Sie oder andere Personen bestimmte Komponenten ersetzen können. In Civ IV könnten Modder beispielsweise Ersatz für die DLLs des Spiels liefern, um Teile des Gameplays grundlegend zu ändern.
• Sie möchten sie zur Laufzeit laden, um die Anwendung um Plugins von Drittanbietern erweitern zu können.

Ein weiterer Vorteil ist, dass Sie damit Ihren Code richtig strukturieren können. Nicht logische Abhängigkeiten zwischen Modulen werden stärker hervorgehoben und es wird schwieriger, solche Hacks zu verwenden.