Shared Libraries (DLL, .so, .dylib)
-
Hi,
ich möchte ein Programm schreiben, welches GUI und Core getrennt implementiert, also GUI z.B. mit C# (auf windows) oder cocoa (auf mac) usw... Dabei werden die Kernfunktionen (Algorithmen) in shared libraries gepackt.
Nun meine Fragen:
-
Ist es möglich eine DLL in C++ zu programmieren, statt C? Ich habe nämlich im Internet irgendwo gelesen, dass "wrapper Funktionen" nötig sind... Muss man also jede C++ Funktion zweimal schreiben, wobei die zweite eine C Funktion ist die C++ Objekte benutzt?? Naja... keine Ahnung hier...
-
Gibt es im Internet Tutorials? Hab nur tutorials für c gefunden...
Danke!
-
-
giowck schrieb:
- Ist es möglich eine DLL in C++ zu programmieren, statt C? Ich habe nämlich im Internet irgendwo gelesen, dass "wrapper Funktionen" nötig sind... Muss man also jede C++ Funktion zweimal schreiben, wobei die zweite eine C Funktion ist die C++ Objekte benutzt?? Naja... keine Ahnung hier...
Jein...
Natürlich kann man DLLs schreiben, welche auch c++ funktionen exportieren. Allerdings wirst du arge probleme haben, eine mit VS erstellte DLL zb mit einer GCC compilierten exe zu verwenden. Daher die C funktionen, die man mit nahezu allem nutzen kann was es an sprachen so gibt.
-
Es gibt in der MSDN und Codeproject entsprechende Artikel dazu. Kurz gesagt:
1. Ja, man kann ohne Schwierigkeiten C++-Klassen in DLLs exportieren und normal nutzen, als wenn sie in einer statischen Library wären.
2. Du mußt in C++ aber alle Komponenten (DLLs und EXE) mit ein und dem selben Compiler bauen. Weil jeder Compiler andere Aufrufkonventionen benutzt und in jedem Programmtask die selbe C++-Runtime für die Speicherverwaltung genutzt werden muß.
3. Wenn du den zweiten Punkt umgehen willst und unterschiedliche Compiler und Runtimes zulassen willst, solltest du es nach COM-Art machen. D.h. Factory-Funktionen benutzen, die die Objekte als Smartpointer zurück geben. So das die DLLs das Management der Objekte übernehmen. So macht es COM und ActiveX unter Windows möglich, doch unterschiedliche Compiler zu nutzen.
Für dein eigenes Projekt sollte aber Punkt 2 kein Hindernis sein, da es auch am komfortabelsten ist. Punkt 3 würde ich nur einsetzen, wenn man seine DLLs an Dritte weiter geben will/muß bzw. Systemweit verfügbar sein soll.
-
-
ok, danke für eure hilfe!!
-
Artchi schrieb:
2. Du mußt in C++ aber alle Komponenten (DLLs und EXE) mit ein und dem selben Compiler bauen. Weil jeder Compiler andere Aufrufkonventionen benutzt und in jedem Programmtask die selbe C++-Runtime für die Speicherverwaltung genutzt werden muß.
Genügt es nicht, nur die Compiler zu verwenden, die sich an die Intel Aufrufkonvention halten, wenn man z.b. die DLL mit g++ erstellt hat, der ja die Intel Konvention selber nutzt?
-
Echjolot schrieb:
Genügt es nicht, nur die Compiler zu verwenden, die sich an die Intel Aufrufkonvention halten, wenn man z.b. die DLL mit g++ erstellt hat, der ja die Intel Konvention selber nutzt?
Nein. Fast alles jenseits von einer schieren C-Schnittstelle (Exceptions, RTTI und dynamic_cast<>, das Klassenlayout, das VMT-Layout, die Symboldekoration, ...) ist compilerspezifisch.
Das absolute Maximum an Portabilität stellt vermutlich "COM Lite" aka von IUnknown abgeleitete Interfaces dar. Auch da mußt du fürs Exception-Marshaling selbst sorgen. Es sei natürlich denn, du verwendest Delphi oder C# - dann kann der Compiler bzw. die Runtime das für dich übernehmen -, aber bei C++ kommst du nicht drum herum.