DLL y STL y datos estáticos (¡oh mi!)

Question

OK ..... He hecho todas las lecturas sobre preguntas relacionadas, y algunos artículos de MSDN, y acerca de un día de búsqueda de Google.

¿Cuál es el "estado del arte" actual respuesta a esta pregunta:

estoy usando VS 2008, C++ código no administrado. Tengo un archivo de solución con bastantes archivos DLL y algunos EXE. Siempre que controle completamente el entorno de construcción, de modo que todas las piezas y partes estén construidas con las mismas banderas, y use las mismas bibliotecas de tiempo de ejecución, y nadie tenga una biblioteca CRT enlazada estáticamente, ¿puedo pasar objetos STL?

Parece que esto debería estar bien, pero dependiendo del artículo que lea, hay mucho miedo, incertidumbre y duda.

Sé que hay todo tipo de problemas con las plantillas que producen datos estáticos detrás de la escena (cada dll obtendría su propia copia, lo que lleva a un dolor de corazón), pero ¿qué pasa con viejo STL normal?

Answer 1

Pasamos satisfactoriamente objetos STL en nuestra aplicación que se compone de docenas de DLL. Para garantizar que funcione, una de nuestras pruebas automáticas que se ejecuta en cada compilación es verificar la configuración de todos los proyectos. Si agrega un nuevo proyecto y lo configura mal, o rompe la configuración de un proyecto existente, la compilación falla.

La configuración que verificamos es la siguiente. Tenga en cuenta que no todos estos problemas causarán problemas, pero los comprobamos en busca de consistencia.

#defines

_WIN32_WINNT 
STRICT 
_WIN32_IE 
NDEBUG 
_DEBUG 
_SECURE_SCL 

opciones del compilador

DebugInformationFormat 
WholeProgramOptimization 
RuntimeLibrary 

Answer 2

Siempre y cuando TODO use la misma versión exacta de las DLL de tiempo de ejecución, no debería haber ningún problema con STL. Pero una vez que tenga varias alrededor, usarán, por ejemplo, montones diferentes, lo que provocará un sinfín de problemas.

Answer 3

Nosotros utilizamos colecciones stl en nuestra aplicación y pasarlos hacia y desde los métodos en diferentes archivos DLL (por lo general como referencias). Esto no causa ningún problema.

La única área en la que hemos tenido problemas es cuando un dll asigna memoria y otro dll intenta eliminarla. Esto solo se informa como malo, pero no estoy seguro de por qué. Sin embargo, solo parece ser un problema en las compilaciones de depuración (donde se informa), pero aún funciona en versiones de lanzamiento. Dicho esto, donde sea que me encuentre, lo soluciono.

Si estaba escribiendo una biblioteca de terceros, lo pensaría dos veces antes de usar los parámetros stl en la API. Previamente (VC6) tuvimos que usar OCI (Oracles C api) en oposición a OCCI (Oracles C++ api) porque solo funcionaba con la implementación STL de Microsoft y estábamos usando stlport. Por supuesto, si habilita a sus clientes para construir la biblioteca con su propia implementación stl esto no es un problema.