Grundlegende Fragen über das Design einer Shared Library in C++ mit Java im Hinterkopf

swaechter

Hallo Nexus

Danke für deinen Antwort. Ich muss ein paar Sachen klarstellen und ergänzen, da ich erst seit gestern in das Thema reingekommen bin und sich der Thread doch recht entwickelt hat. Früher habe ich Libraries einfach exportiert und das wars - mehr nicht (Schnittstelle und Implementierung = Eine Klasse). Seit gestern habe ich mich vertieft damit auseinandergesetzt, um das ganze sauberer gestalten zu können. Zu ergänzen (meinerseits) ist:

Infrastruktur
- Ich verwende für die Applikation und die Library denselben Compiler und dasselbe CRT (Sprich MSVC und dessen CRT oder GCC/Clang und dessen GLIBC)
- Es kann vorkommen, dass die Applikation wegen Änderungen in der Library nicht neukompiliert wird (Wir reden über eine Patch Level Änderung in der Library, nicht Major & Minor, deshalb muss gewährleistet sein, dass sich das Offset nicht ändert (Z.B neue Variable wird eingeführt). ANMERKUNG: Ich habe mich noch nicht vertieft in Offset Changing eingelesen. Wird das ganze über eine lose Kopplung realisiert, funktioniert die Applikation auch mit der geupdateter Library. Verwende ich aber 1 Klasse wie bereits mehrmals in diesem Thread vorgeschlagen wurde, ist es (gut) möglich, dass sich das Offset der Library ändert [und das der Applikation nicht, da kein recompile].Das CRT zwischen Applikation und Library bleibt aber auch in diesem Fall gleich (Build Server)

Betreffend deiner Aussage 1:
- Wird deine Aussage nicht eher unwichtig/rückt in den Hintergrund, wenn ich garantieren kann, dass ich denselben Compiler und dasselbe CRT verwenden kann. Es erfolgt definitv kein Compiler/CRT Mixing ! Entweder kompiliert das Buildsystem ALLES oder nur Änderungen, aber immer mit dem gleichen Compiler/CRT.

Betreffend deiner Aussage 2:

Nexus schrieb:

Du solltest dir also überlegen, wie weit du deswegen dein Design verkomplizieren willst.

Wie darf man das verstehen. Könntest Du mir ein komplettes Codebeispiel geben, wie Du es machen würdest, wenn dir jemand den Auftrag gibt, eine Klasse zu schreiben, welche Projekte und Eintrage machen/editieren/löschen kann, WENN Du davon ausgehen kannst, dass der Compiler und das CRT IMMER dasselbe sind und eine lose Kopplung von Nöten ist ? Ich wär dir dafür sehr dankbar.

Schöne Weihnachten dir & Mitleser
Gruss Simon

firefly

Bezüglich ABI kompatiblen Änderungen in Klassen:

AFAIK ändert sich die ABI Schnittstelle einer Klasse nicht, wenn ein neuer Member(eine neue Memeber-Methode?) immer ans ende der Klassen definition gepackt wird.

Wobei ich nicht weis, ob sich die ABI eventuell ändert, wenn eine Änderung in einer Klasse gemacht wird, welche als Basis für andere Klassen Verwendung findet

hustbaer

firefly schrieb:

Bezüglich ABI kompatiblen Änderungen in Klassen:

AFAIK ändert sich die ABI Schnittstelle einer Klasse nicht, wenn ein neuer Member(eine neue Memeber-Methode?) immer ans ende der Klassen definition gepackt wird.

Bei nicht-statischen Datenmembern wird die Klasse dadurch bei allen Systemen die ich kenne inkompatibel, da sich sizeof(T) ändert.

Neue Methoden sind dagegen meist egal. So lange sie nicht virtuell sind, ist dabei auch egal wo man sie dazuschreibt. Und wenn sie virtuell sind, man sie aber brav hinter alle anderen virtuellen Funktionen schreibt, dann ist es auch egal. Zumindest eben auf den Systemen nicht ich kenne.

Hat aber mit Standard C++ nix zu tun, da der Standard diesbezüglich nix vorschreibt.

Wobei ich nicht weis, ob sich die ABI eventuell ändert, wenn eine Änderung in einer Klasse gemacht wird, welche als Basis für andere Klassen Verwendung findet

Wenn nicht-statische Datenmenber betroffen sind, ist die Chance gross, dass alle abgeleiteten Klassen neu übersetzt werden müssen. Wenn sich die Grösse oder das Layout der Klasse bzw. abgeleiteten Klassen dadurch ändert auch der gesamte Client Code.

Sowas sind aber Dinge über die ich mir üblicherweise nicht den Kopf zerbreche.
Für mich gibt es ein paar sinnvolle Varianten damit umzugehen:
* Reines C Interface
* COM
* PIMPL
* volles C++ Interface + immer alles neu Übersetzen

Zwischenlösungen mache ich da nur wenn ich wirklich muss. Was in den letzten Jahren nicht vorgekommen ist. Ich hab' aber auch nur mehr ein Projekt wo ich ein stabiles binary Inteface garantieren muss, und das verwendet COM.