I’ve looked at various online articles on ‘template instantiation declaration to export the STL class instantiation from the DLL’, but it seems very hairy, and might not work on all STL containers. So I just wrote a small wrapper class around Point2D, called Point2D_Int and exported it with __declspec(dllexport). Point2D_Int contains a member variable that’s a pointer to the actual Point2D, which contains the std::vector. The compiler warning went away! Is this a good idea? Is it alright to use the STL in a DLL’s internal classes like this? Will I end up with weird linker errors later on? ‘The only STL container that can currently be exported is vector. The other containers (that is, map, set, queue, list, deque) all contain nested classes and cannot be exported.’ If I can only do vectors, then it isn’t a solution I can generally apply to my code, which has all sorts of stl::containers as member variables. kbw: By ‘exporting’ data, do you mean I should never have a publicly-exposed member variable? What if I write an accessor for it? Exporting classes with private data is fine. And that goes for any data, vectors, maps, sets, your own classes that have these things … The issue with with how the C/C++ runtime is shared. Of course, they can only share it if they link to it at runtime. Binding to the static runtime libs is unhelpful because: Source.