DLL et STL et données statiques (oh mon!)

Question

OK ..... J'ai fait toute la lecture sur des questions connexes, et quelques articles MSDN, et sur une journée de googling.

Quel est le "état de l'art" actuel réponse à cette question:

J'utilise VS 2008, C++ code non managé. J'ai un fichier de solution avec un certain nombre de DLL et un certain nombre d'EXE. Tant que je contrôle complètement l'environnement de construction, de sorte que toutes les pièces et parties sont construites avec les mêmes drapeaux et utilisent les mêmes librairies d'exécution, et que personne n'a de bibliothèque CRT liée statiquement, est-ce que je peux passer des objets STL?

Il semble que cela devrait être OK, mais selon l'article que vous avez lu, il y a beaucoup de Peur, d'Incertitude et de Doute.

Je sais qu'il y a toutes sortes de problèmes avec les modèles qui produisent des données statiques en coulisses (chaque DLL aurait sa propre copie, conduisant à chagrin d'amour), mais qu'en est-il de l'ancienne STL?

Answer 1

Nous passons avec succès les objets STL dans notre application qui est composée de dizaines de DLL. Pour s'assurer que cela fonctionne l'un de nos tests automatisés qui s'exécute à chaque build est de vérifier les paramètres de tous les projets. Si vous ajoutez un nouveau projet et que vous le configurez incorrectement, ou cassez la configuration d'un projet existant, la construction échoue.

Les paramètres vérifiés sont les suivants. Notez que tous ces problèmes ne seront pas problématiques, mais nous les vérifions pour vérifier leur cohérence.

#defines

_WIN32_WINNT 
STRICT 
_WIN32_IE 
NDEBUG 
_DEBUG 
_SECURE_SCL 

options de compilation

DebugInformationFormat 
WholeProgramOptimization 
RuntimeLibrary 

Answer 2

Tant qu'ils utilisent tous la même version des DLL d'exécution, il ne devrait pas y avoir de problème avec STL. Mais une fois que vous en avez plusieurs autour, ils vont utiliser par exemple différents tas - menant à aucune fin de problèmes.

Answer 3

Nous utilisons des collections stl dans notre application et les passer à des méthodes et dans différentes dll (habituellement comme références). Cela ne pose aucun problème.

La seule zone où nous avons eu des problèmes est où une DLL alloue de la mémoire et une autre DLL tente de le supprimer. Ceci est seulement signalé comme mauvais, mais je ne sais pas pourquoi. Cependant, cela semble seulement être un problème sur les versions de Debug (où cela est rapporté), mais fonctionne toujours sur les versions de versions. Cela dit, là où je tombe sur ça, je le répare.

Si j'écrivais une bibliothèque tierce, j'y réfléchirais à deux fois avant d'utiliser les paramètres stl dans l'API. Auparavant (VC6), nous devions utiliser l'OCI (Oracles C api) par opposition à l'OCCI (Oracles C++ api) car cela ne fonctionnait qu'avec l'implémentation Microsoft STL et nous utilisions stlport. Bien sûr, si vous permettez à vos clients de construire la bibliothèque avec leur propre implémentation stl, ce n'est pas un problème.