Microsoft has had a fair amount of trouble in the past when passing STL containers like string and vector pointers and references to DLLs. See, for example, You may experience an access violation when you access an STL object through a pointer or reference in a different DLL or EXE.

Question: Are those types of problems still present today in Visual Studio 2010 and 2013?

I know the question is a bit open-ended. I am asking because I've experienced them in the past, I'm working on a new design, the design could include a plugin architecture, and I would like to to pass a string or vector reference to a plugin DLL. If the problems still plague Microsoft, then I have to change the design (or come up with a workaround to avoid the crash).

Related, Did C++11 address concerns passing std lib objects between dynamic/shared library boundaries? is similar (thanks for the link). But it does not really answer the question, though it does seem to acknowledge the same problem.

Also, Microsoft's KB Q168958, How to export an instantiation of a Standard Template Library (STL) class and a class that contains a data member that is an STL object, implies it can be done. But that's around the time I recall having the problems, so I am curious if it still applies (and if it actually works now in Visual Studio 2010 or 2013).

The problem I am running into was highlighted by Robert and Doc: I can test for the presence of bugs, but not the absence of them. So I might not be able to trigger problems during testing, but the problems may really exists (and surface at the worse time).

  • It would be easy enough to test. Apr 8, 2015 at 5:22
  • 3
    @RobertHarvey: I do not think its easy to test - just because some small test case works does not proof passing STL containers between DLLs will be reliable.
    – Doc Brown
    Apr 8, 2015 at 5:46
  • 2
    Short answer because I'm on my phone, yes, you'll have problems, because of a variety of reasons boiling down to no standard for binary compatibility. Possible solutions are to expose a pure C interface, or use COM. Apr 8, 2015 at 5:57
  • 1
    Official position is still the same, no, all standard library objects which are not "standard layout" (formerly called plain-old-data types, or POD) may have layout changes across versions. msdn.microsoft.com/en-us/library/bb531344.aspx
    – rwong
    Apr 8, 2015 at 7:42
  • 3
    Mixing and matching dynamic or static libraries compiled by different versions of compilers is always a no-no, unless only "standard layout" (POD) data structure is involved. In C++, typically one recompiles everything with the same version of compiler. This is why C++ really forces vendors to consider open-source because it is likely that customers will need to recompile from source code with a newer compiler version in the future, after the vendor's initial release.
    – rwong
    Apr 8, 2015 at 7:45

1 Answer 1


Export a C interface.

Not only does that solve the DLL problem, but it allows for plugins in languages other than C++.

Then write a C++ wrapper for the C API as a header only library.

You can't use C++ non-standard-layout objects in the API because there is no standard ABI for them, so you would be requiring the library and users to all be compiled with the same compiler and libraries. This is particularly bad for plugins -- it is less of an issue for libraries as the library user can statically link the library with the executable, or at least bundle the two in a single installer.

Note that a non-POD object can still be standard layout, starting with C++11.