DLLs und STLs und statische Daten (oh mein!)

Question

OK ..... Ich habe die ganze Lesung zu verwandten Fragen und ein paar MSDN-Artikel und über einen Tag im Wert von googeln getan.

Was auf diese Frage der aktuellen „Stand der Technik“ Antwort ist:

ich VS 2008, C++ nicht verwalteten Code verwenden. Ich habe eine Lösungsdatei mit ziemlich vielen DLLs und ziemlich vielen EXEs. Solange ich die Build-Umgebung vollständig kontrolliere, so dass alle Teile und Teile mit denselben Flags erstellt werden und dieselben Laufzeitbibliotheken verwenden und niemand über eine statisch verknüpfte CRT-Bibliothek verfügt, bin ich ok, um STL-Objekte herumzugeben?

Es scheint, als sollte dies in Ordnung sein, aber je nachdem, welchen Artikel Sie lesen, gibt es eine Menge Angst, Unsicherheit und Zweifel.

Ich weiß, es gibt alle möglichen Probleme mit Vorlagen, die statische Daten hinter den Kulissen erzeugen (jede DLL würde ihre eigene Kopie bekommen, was zu Herzschmerz führen würde), aber was ist mit normalen alten STL?

Answer 1

Wir übergeben erfolgreich STL-Objekte in unserer Anwendung, die aus Dutzenden von DLLs besteht. Um sicherzustellen, dass es funktioniert, ist einer unserer automatisierten Tests, die bei jedem Build ausgeführt werden, um die Einstellungen für alle Projekte zu überprüfen. Wenn Sie ein neues Projekt hinzufügen und es falsch konfigurieren oder die Konfiguration eines vorhandenen Projekts unterbrechen, schlägt der Build fehl.

Die Einstellungen, die wir prüfen, sind wie folgt. Beachten Sie, dass nicht alle Probleme auftreten, aber wir prüfen sie auf Konsistenz.

#defines

_WIN32_WINNT 
STRICT 
_WIN32_IE 
NDEBUG 
_DEBUG 
_SECURE_SCL 

Compiler-Optionen

DebugInformationFormat 
WholeProgramOptimization 
RuntimeLibrary 

Answer 2

Solange sie alle genau die gleiche Version der Laufzeit-DLLs verwenden, sollte es kein Problem mit STL geben. Aber sobald Sie mehrere haben, werden sie zum Beispiel verschiedene Haufen verwenden - was zu einem Ende der Probleme führt.

Answer 3

Wir verwenden stl Sammlungen in unserer Anwendung und geben sie nicht an und von Methoden in verschiedenen DLLs (in der Regel als Referenzen). Dies verursacht keine Probleme.

Der einzige Bereich, in dem wir Probleme hatten, ist, wo eine DLL Speicher reserviert und eine andere DLL versucht, sie zu löschen. Dies wird nur als schlecht gemeldet, aber ich bin mir nicht sicher warum. Es scheint jedoch nur ein Problem bei Debug-Builds (wo es gemeldet wird) zu sein, funktioniert aber immer noch bei Release-Builds. Nachdem ich das gesagt habe, wo auch immer ich darauf stoße, repariere ich es.

Wenn ich eine 3rd-Party-Bibliothek schrieb, würde ich zweimal darüber nachdenken, stl-Parameter in der API zu verwenden. Vorher (VC6) mussten wir die OCI (Oracles C api) im Gegensatz zu OCCI (Oracles C++ api) verwenden, da es nur mit der Microsoft STL-Implementierung funktionierte und wir stlport verwendeten. Natürlich, wenn Sie Ihren Kunden ermöglichen, die Bibliothek mit ihrer eigenen stl-Implementierung zu erstellen, ist dies kein Problem.