4. Probleme mit statischer Bibliothek im Debug-Modus

Probleme mit statischer Bibliothek im Debug-Modus

  • B

    Nexus schrieb:

    Gibt es keine andere Möglichkeit, als 4 statische Bibliotheken (.lib) zu erstellen, wenn man sowohl dynamische als auch statische CRT-Linkage und auch Debug- und Release-Modus ermöglichen will?

    Ich bin mir zumindest relativ sicher, dass es nicht anders geht. Nicht zu vergessen, diese 4 Libs übrigens ja nur pro Compilerversion 😃

    0
  • N

    Badestrand schrieb:

    Nicht zu vergessen, diese 4 Libs übrigens ja nur pro Compilerversion 😃

    Und ich dachte, statische Bibliotheken wären ein guter Weg zur Wiederverwendung von Code... 🙄

    Wahrscheinlich werde ich den Benutzer einfach zwingen, MSVC++ mit dynamischer CRT-Linkage zu verwenden... 😃

    Aber wie ist das bei anderen Bibliotheken, z.B. Boost, gelöst? Gibt es da für alle existierenden Compiler eigene Libs?

    0

  • Nein! Es gibt IMHO keine andere Möglichkeit.
    Statisch/Dynamisch, Debug/Non-Debug macht leider 2x2=4
    Und das je Compiler Version...

    0
  • N

    Okay, danke für die Antworten.
    Dann werd ich mir das halt wohl oder übel antun müssen. 😞

    Naja, so viel zu Code-Wiederverwendung... Irgendwie beschleicht mich das Gefühl, eine eigene CPP-Datei statt einer Lib mitzuliefern wäre einfacher... 🙄

    0

  • Nexus schrieb:

    Naja, so viel zu Code-Wiederverwendung... Irgendwie beschleicht mich das Gefühl, eine eigene CPP-Datei statt einer Lib mitzuliefern wäre einfacher... 🙄

    Warum lieferst Du nicht eine DLL aus, und dazu eine Import-LIB?

    0
  • N

    Martin Richter schrieb:

    Warum lieferst Du nicht eine DLL aus, und dazu eine Import-LIB?

    Aber für die Import-Lib hätte man wieder das gleiche Problem, oder?

    0

  • Eben nicht! Die enthält keinen Code, sondern nur Referenzen auf die DLL.

    Wichtig ist dann aber, dass aber Schnittstelle nicht geschludert wird und nicht mit STL Containern und CString etc, gearbeitet wird.
    Was glaubst Du wie die Anbindung an die MS API erfolgt? Die ist komplett Compiler unabhängig.

    0
  • N

    Okay, danke.

    Aber nicht mit der STL zu arbeiten, empfinde ich als starke Einschränkung... Zu was verliert man Kompatibilität, wenn man sie doch einsetzt?

    0
  • N

    Wäre noch aktuell...

    Was darf man beim Verwenden eigener DLLs nicht verwenden und weshalb nicht, und zu was verliert man die Kompatibilität, wenn man es doch tut?

    0
  • B

    Nexus schrieb:

    Was darf man beim Verwenden eigener DLLs nicht verwenden und weshalb nicht, und zu was verliert man die Kompatibilität, wenn man es doch tut?

    Soweit ich weiß darf die Schnittstelle nur Builtins enthalten, nicht mal Structs (evtl unterschiedliches Padding) und schon gar keine Klassen (evtl alles unterschiedlich).

    edit: Wie macht das eigentlich die WinAPI mit structs? edit2: => Ich hab Unrecht 😃

    0

  • PODs gehen in Ordnung. Auch Zeiger zur Not, wenn klar ist wer sie wieder frei gibt.
    In der WinAPI wird das Padding (pragma pack) im Header mit angegeben.

    Die STL ist ganz klar etwas was man unbedingt meiden muss, denn der Austausch hier ist dann immer Compiler abhängig. Das binäre Format ändert sich eben.
    Solch eine DLL (auch als Import,DLL) könnte man nie zwischen mehreren Compiler Versionen verwenden und das ist ja eigentlich der Sinn von DLLs, dass diese unabhängig sein sollen.

    Natürlich: Sie müssen es nicht! Unsere Applkation wird auch mit Kern-DLLs ausgeliefert, die immer zusammen mit der EXE gebaut werden und nie einzeln getauscht werden.

    0
Anmelden zum Antworten