DLLs and STLs and static data (oh my!)

问题:

OK..... I've done all the reading on related questions, and a few MSDN articles, and about a day's worth of googling.

What's the current "state of the art" answer to this question:

I'm using VS 2008, C++ unmanaged code. I have a solution file with quite a few DLLs and quite a few EXEs. As long as I completely control the build environment, such that all pieces and parts are built with the same flags, and use the same runtime libaries, and no one has a statically linked CRT library, am I ok to pass STL objects around?

It seems like this should be OK, but depending on which article you read, there's lots of Fear, Uncertainty, and Doubt.

I know there's all sorts of problems with templates that produce static data behind the scenes (every dll would get their own copy, leading to heartache), but what about regular old STL?

回答1:

We successfully pass STL objects around in our application which is made up from dozens of DLLs. To ensure it works one of our automated tests that runs at every build is to verify the settings for all projects. If you add a new project and misconfigure it, or break the configuration of an existing project, the build fails.

The settings we check are as follows. Note not all of these will cause issues, but we check them for consistency.

#defines

_WIN32_WINNT
STRICT
_WIN32_IE
NDEBUG
_DEBUG
_SECURE_SCL

Compiler options

DebugInformationFormat
WholeProgramOptimization
RuntimeLibrary

回答2:

As long as they ALL use the exact same version of runtime DLLs, there should be no problem with STL. But once you happen to have several around, they will use for instance different heaps - leading to no end of troubles.

回答3:

We use stl collections in our application and pass them to and from methods in different dlls (usually as references). This doesn't cause any trouble.

The only area where we have had trouble is where one dll allocates memory and another dll tries to delete it. This only is reported as bad, but I am not sure why. However it only seems to be a problem on Debug builds (where it is reported), but still works on release builds. Having said that where ever I come across this I do fix it.

If I was writing a 3rd party library I would think twice about using stl parameters in the api. Previously (VC6) we had to use the OCI (Oracles C api) as opposed to OCCI (Oracles C++ api) because it only worked with the Microsoft STL implementation and we were using stlport. Of course if you enable your clients to build the library with their own stl implementation this is not an issue.