DLL-Project in mehrere DLLs splitten

Hi, ich programmiere ein großes Framework und möchte dieses nun in mehrere DLLs aufsplitten. Ich finde das ganze aber noch ziemlich verwirrend. Bislang war alles in einer einzigen DLL untergebracht. Wie sollte ich also dabei vorgehen? Zunächst habe ich ein Visual Studio Projekt angelegt und dort für jede DLL ein weiteres DLL-Projekt (Dynamic) hinzugefügt und die entsprechenden Sourcen verlinkt und zwei dutzend Konfigprofile (x86, x64, Debug, Release, ...) angelegt (Ich glaube komplizierter hätte Microsoft das nicht lösen können). Die Sourcen sind übrigens alle in einem Verzeichnis (mit Unterverzeichnissen).

Brauche ich dann für jede DLL ein Macro wie dieses:

#ifdef DLL1_EXPORTS
  #define DLL1_API __declspec(dllexport)
#else
  #define DLL1_API __declspec(dllimport)
#endif

#ifdef DLL2_EXPORTS
  #define DLL2_API __declspec(dllexport)
#else
  #define DLL2_API __declspec(dllimport)
#endif

Oder kann ich in jeder DLL das gleiche Macro benutzen? Und was ist wenn die DLLs untereinander verlinkt sind. Ich also z.B. eine Klasse "Base" in DLL1 habe die aber auf eine Klasse "Derived" zurückgreift, die in DLL2 vorhanden ist? Werden beim Kompilieren dann evtl. alle nötigen Komponenten in die DLL1 gepackt, man also unter Umständen auch Teile aus DLL2 in DLL1 hat? Oder sind die DLLs dann nur voneinandner abhängig/verlinkt oder geht das womöglich alles überhaupt nicht.

class DLL1_API Base
{
public:
    Base(){};

private:
    Derived m_derived
};

class DLL2_API Derived : public Base
{
public:
    Derived(){};
};

Mechanics

Mach es Sinn, ein Framework in mehrere Dlls aufzuteilen?

Ja, das Macro bräuchtest du für jede Dll, aber wo ist das Problem? Wenn die Cpp Datei mit der Klasse nicht zum Dll Projekt gehört, wird es da auch nicht reinkompiliert.

Das Problem ist, dass DLL2 die DLL1 einbindet (#pragma comment(lib, "dll1.lib")). DLL1 verwendt aber eine Klasse aus DLL2. Sprich DLL1 versucht sich wegen des pragma ... selbst einzubinden was natürlich nicht funktioniert, da ich DLL1 ja gerade erst erstellen möchte. Da beißt sich die Katze in den Schwanz. Ich fürchte dann muss man ganz strikt trennen. Nur ob sich das bei über 400 Klassen realisieren lässt weiß ich noch nicht.

Sinn macht das schon. Stell dir mal vor du hast eine Core.dll in der ganz essentielle Bestandteile sind. Außerdem noch eine GUI.dll in der die Komponenten der Benutzeroberfläche sind. Oder noch eine XML.dll die einen Xml-Parser enthält. Jetzt gibt es aber Kunden die möchten nur die Core- und XML.dll weil sie z.B. ihre GUI mit einem anderen Framework erstellen möchten.

oenone

Gegenseitige Abhängigkeiten sind immer unschön. Aber guck dir mal den Artikel an:

http://msdn.microsoft.com/de-de/library/fdy23fx6.aspx

Die meisten DLL-Projekte mit mehreren DLLs (wie Qt) werden wohl strikte Trennungen haben, also eine Basis-DLL, die von nichts abhängig ist und die anderen darauf aufbauend, aber nie wechselseitig.

hustbaer

Enumerator schrieb:

Das Problem ist, dass DLL2 die DLL1 einbindet (#pragma comment(lib, "dll1.lib")). DLL1 verwendt aber eine Klasse aus DLL2. Sprich DLL1 versucht sich wegen des pragma ... selbst einzubinden was natürlich nicht funktioniert, da ich DLL1 ja gerade erst erstellen möchte. Da beißt sich die Katze in den Schwanz.

Also erstmal geht das sehrwohl.
Dabei muss man erstmal DLL1.LIB bauen, und zwar nur DLL1.LIB, ohne DLL1.DLL. Das geht. Und dazu ist DLL2.LIB nicht nötig, selbst wenn DLL2.LIB in DLL1 eingebunden wird.
Dann hat man DLL1.LIB und kann ganz normal DLL2 bauen.
Und dann hat man DLL2.LIB und kann ganz normal DLL1 bauen.

Nur stellt sich dabei die Frage: warum dann überhaupt irgendwas aufteilen?
Wenn du nämlich so einen Fall hast, dann kann die "Trennlinie" die du da zwischen DLL1 und DLL2 gezogen hast unmöglich sinnvoll sein.

=> Teil die Sache so auf, dass du keine zyklischen Abhängigkeiten zwischen den DLLs hast.