Hallo Martin,
Wir haben also hier eine betriebssystemspezifische Schnittstelle zwischen verschiedenen Programmmodulen, die nicht auf jedem System überhaupt existieren muss und die auf einem gegebenen System (Linux, Windows) auch nicht von der verwendeten Programmiersprache C/C++ abhängig ist. Eine in Assembler/Delphi/VB geschriebene DLL hätte die gleiche Schnittstelle.
Nicht zwangsläufig. Wenn ich (jetzt mal unter Linux, unter Windows ist's aber im Prinzip genauso) ein folgende Bibliothek habe:
extern int testfunc (int a) {
return a / 2;
}
Das ist sowohl gültiges C als auch gültiges C++. Wenn ich das nun kompiliere:
------------------------------------------
gcc -Wall -shared -o lib.so lib.c
g++ -Wall -shared -o libxx.so libxx.cc
------------------------------------------
(lib.c und libxx.cc sind identisch und enthalten den obigen Code; gcc ist der C-Compiler auf meinem System, g++ der C++-Compiler)
Wenn ich mir nun die Symbole der beiden Bibliotheken ausgeben lassen, dann erhalte ich:
------------------------------------------
christian@midnight ~/selfhtml/test $ strings libxx.so | grep testfunc
_Z8testfunci
christian@midnight ~/selfhtml/test $ strings lib.so | grep testfunc
testfunc
------------------------------------------
Im Falle der C++-Bibliothek werden also (da man C++-Bibliotheken Funktionen überladen kann, in C-Bibliotheken nicht) noch Typinformationen an den Funktionsnamen angehängt, im Fall der C-Bibliothek nicht. Wenn ich bei der C++-Bibliothek noch ein extern "C" { }
drum rum mache, ist der Funktionsname wieder »testfunc« (und nicht »_Z8testfunci«).
Die Schnittstelle, die eine Bibliothek besitzt, ist also auch von der Programmiersprache abhängig. Natürlich gibt es bestimmte Konventionen, die eine Bibliothek auf einem bestimmten Betriebsystem einhalten _muss_.
Viele Grüße,
Christian