Dll's sind doch nichts weiter als eine Ansammlung von Funktionen/Klassen, welche standardisiert zur Verfügung stehen sollen.
Ob ich jetzt eine Klasse anlege mit *.cpp/*.h Dateien oder diese Klasse aus einer Lib heraus benutzt macht keinen Unterschied.
Naja, das ist sehr blauaeugig erklärt.
Es gibt unterschiede, die liegen, wie so oft, aber im Detail. Aber dafuer sind oft recht heftig
ne dynamische Bib ziehst an, in dem die Bib, also deren code in nen seperaten speicher lädst. Die exportierten funktionen per FPointer holst, und damit dann anspringst.
mehr kann ne dll nicht.
Nun zu dem "Detail":
Dll sind eigene Übersetzungseinheiten !
Das heisst sie werden seperat gelinkt ...
das heisst, es könnte ein anderer Compiler sein ... der die dll baut
das heisst, es koennten gewisse Flags anders sein (die beim linken einer lib knallen wuerden ... )
Das bringt paar "Probleme" mit sich.
Alle symbole, auf die von Funktions-Deklarationen im Export verwiesen wird, muessen in der dll und in der exe bekannt sein (templates sind da ganz boese z.b.)
Alle Speicherobjecte die in den Funktions-Deklarationen stecken, muessen binaer den gleichen Aufbau haben (da tun sich Objecte (Klassen) etwas schwer ! Methodenausrichtung, lage der Vtable etc ... Deshalb Faustregel, dll mit Klassen Interface immer nur mit selben Compiler bei exe und dll ! Auch wenns ned ganz korrekt ist ... )
Daraus leiten sich eigentlich alle weiteren Probleme ab
Blöde Frage am Rande, wie kann die DLL dann auf Dinge, wie zB Datenbankverbindung zugreifen?? Sprich, kann eine DLL auf Objekte der Anwendung zugreifen??
Geht, mit paar DIngen die beachtet werden muessen.
Die definitionen rund um die Instanz muessen in der dll natuerlich bekannt und auch compatibel sein ...
das symbol muss aus Sicht der Dll als extern deklariert sein (was nicht nur mit dem schluesselwort extern geht). Oder ueber zentrale zugriffsmethoden geleitet werden, die in den Code der exe oder ner anderen dll verweissen und diese wiederum auf ein Object an bestimmter stelle verweissen.
Ciao ...