Ist es sicher, eine standardkonforme STL in einer Bibliothek und eine andere in einem Projekt zu verwenden, das diese Bibliothek verwendet? Zum Beispiel:
%Vor%Es scheint mir, dass schlimme Dinge passieren werden, besonders wenn es sich nicht um eine einfache Zeichenfolge handelt, sondern um etwas komplizierteres wie tr2 :: thread. Aber wenn ja, wie kann ich eine Bibliothek in einem Compiler kompilieren und die Bibliotheksbenutzer ihren bevorzugten Compiler für ihre Projekte frei wählen lassen?
Wenn - nach Bibliothek - Sie meinen dynamische Bibliothek - Die einfache Antwort ist: Nein und die komplexe Antwort lautet: Nein.
C ++ und dynamische Bibliotheken ist eine sehr sehr fragile Aussicht. Jede kleine Änderung erfordert eine Neuerstellung aller Module, und die Laufzeit, die von jeder Bibliothek verwendet wird, MUSS genau dieselbe Bibliotheksinstanz sein.
Selbst wenn Sie es geschafft haben, eine std :: string über eine dll Grenze zu bekommen - während die externe Schnittstelle von std :: string fest ist, werden alle Implementierungsunterschiede die Daten als beschädigt erscheinen lassen.
Es ist nur sicher, einfache POD-Strukturen und native Datentypen zwischen dynamischen Bibliotheken zu übergeben, wenn die Laufzeiten möglicherweise unterschiedlich sind - und selbst dann muss die Lebensdauer der Objekte korrekt gehandhabt werden - die zuzuweisende Bibliothek MUSS die entziehende Bibliothek sein.
Wenn Sie statische Bibliothek meinen - das macht keinen großen Sinn - glaube ich nicht, dass libs von MinGW kompatibel mit MSDev und MSDev libs sind nicht kompatibel mit MinGW. Selbst wenn das lib-Dateiformat nominal kompatibel sein sollte - vorausgesetzt, die verschiedenen Namen-Manglings führen nicht zu einem erfolgreichen Ling: Die STL-Bibliothek der endgültigen Verknüpfungsumgebung würde verwendet werden.
Ist es sicher, eine standardkonforme STL in einer Bibliothek und eine andere in einem Projekt zu verwenden, das diese Bibliothek verwendet?
Nein.
Einige Teile von STL zur Wiederverwendbarkeit werden in eine gemeinsame Bibliothek gestellt. Es ist unmöglich zu garantieren, dass die interne Struktur von Klassen in den verschiedenen STLs übereinstimmt, was zu sporadischen Abstürzen führt, wenn beide von einem Programm synonym verwendet werden.
Beachten Sie auch, dass STLs von verschiedenen Herstellern unterschiedliche interne Namespaces und Klassen haben können. Das hat zur Folge, dass das öffentliche Symbol% co_de% möglicherweise andere interne Namen hat und anders gemangelt würde, was std::basic_string und void Foo(std::string& str_mingw); aus Linkerperspektive zu zwei verschiedenen Funktionen macht.
Es hängt von der Bibliothek, der Plattform und davon ab, wie Sie es kompilieren und verknüpfen. Oft (insbesondere unter Windows) werden Bibliotheken als DLLs verteilt, und es gibt sehr spezifische Regeln darüber, was an den Grenzen sein kann und wie sie jeweils kompiliert werden müssen.
Boost zum Beispiel erstellt DLLs für:
Siehe Ссылка für die Permutationen.
>Also ja, es ist ein großes Problem.
Ist es sicher, einen Standard zu verwenden? konforme STL in einer Bibliothek und ein anderer in einem Projekt, das das nutzt Bibliothek? ...
void Foo(std::string& str_mingw);...Foo(str_vstudio);
Nein. Es hat nicht einmal zu viel mit dynamischen Bibliotheken zu tun. Selbst wenn Sie es irgendwie geschafft haben, sowohl die MS std :: string als auch die minGW std :: string in die gleiche ausführbare Datei zu bringen, würde sie trotzdem brechen. Sie haben zwei verschiedene (wahrscheinlich unterschiedliche) Definitionen von std :: string in Ihrem Programm und wenn Sie sie mischen, befinden Sie sich in undefiniertem Verhaltensland.
Beachten Sie jedoch, dass es funktionieren würde, wenn Ihre std :: string nicht in der Schnittstelle verwendet wird. Das heißt: Sie können eine Bibliothek verwenden, die MinGW-Zeichenfolgen intern verwendet, und eine andere Bibliothek, die VC-Zeichenfolgen intern verwendet, solange Sie const char * (als Beispiel) auf der Schnittstellenebene verwenden.