Exporting classes containing std:: objects (vector

Question

I'm trying to export classes from a DLL that contain objects such as std::vectors and std::strings - the whole class is declared as dll export through:

    class DLL_EXPORT FontManager
{

The problem is that for members of the complex types I get this warning:

warning C4251: 'FontManager::m__fonts' : class 'std::map<_Kty,_Ty>' needs to have dll-interface to be used by clients of class 'FontManager' with [ _Kty=std::string, _Ty=tFontInfoRef ]

I'm able to remove some of the warnings by putting the following forward class declaration before them even though I'm not changing the type of the member variables themselves:

template class DLL_EXPORT std::allocator<tCharGlyphProviderRef>;
template class DLL_EXPORT std::vector<tCharGlyphProviderRef,std::allocator<tCharGlyphProviderRef> >;
std::vector<tCharGlyphProviderRef> m_glyphProviders;

Looks like the forward declaration "injects" the DLL_EXPORT for when the member is compiled but is it safe? Does it realy change anything when the client compiles this header and uses the std container on his side? Will it make all future uses of such a container DLL_EXPORT (and possibly not inline?)? And does it really solve the problem that the warning tries to warn about?

Is this warning anything I should be worried about or would it be best to disable it in the scope of these constructs? The clients and the dll will always be built using the same set of libraries and compilers and those are header only classes...

I'm using Visual Studio 2003 with the standard STD library.

---- Update ----

I'd like to target you more though as I see the answers are general and here we're talking about std containers and types (such as std::string) - maybe the question really is:

Can we disable the warning for standard containers and types available to both the client and the dll through the same library headers and treat them just as we'd treat an int or any other built-in type? (It does seem to work correctly on my side.) If so would should be the conditions under which we can do this?

Or should maybe using such containers be prohibited or at least ultra care taken to make sure no assignment operators, copy constructors etc will get inlined into the dll client?

In general I'd like to know if you feel designing a dll interface having such objects (and for example using them to return stuff to the client as return value types) is a good idea or not and why - I'd like to have a "high level" interface to this functionality... maybe the best solution is what Neil Butterworth suggested - creating a static library?

Answer 1

Found this article. In short Aaron has the 'real' answer above; Don't expose standard containers across library boundaries.

Answer 2

Though this thread is pretty old, I found a problem recently, which made me think again about having templates in my exported classes:

I wrote a class which had a private member of type std::map. Everything worked quite well untill it got compiled in release mode, Even when used in a build system, which ensures that all compiler settings are the same for all targets. The map was completely hidden and nothing was directly exposed to the clients.

As a result the code was just crashing in release mode. I gues, because different binary std::map instances were created for implementation and client code.

I guess the C++ Standard is not saying anaything about how this shall be handled for exported classes as this is pretty much compiler specific. So I guess the biggest portability rule is to just expose Interfaces and use the PIMPL idiom as much as possible.

Thanks for any enlightenment

Answer 3

There are other issues.

Some STL containers are "safe" to export (such as vector), and some aren't (e.g. map).

Map for instance is unsafe because it (in the MS STL distribution anyway) contains a static member called _Nil, the value of which is compared in iteration to test for the end. Every module compiled with STL has a different value for _Nil, and so a map created in one module will not be iterable from another module (it never detects the end and blows up).

This would apply even if you statically link to a lib, since you can never guarantee what the value of _Nil will be (it's uninitialised).

I believe STLPort doesn't do this.

Answer 4

One alternative that few people seem to consider is not to use a DLL at all but to link statically against a static .LIB library. If you do that, all the issues of exporting/importing go away (though you will still have name-mangling issues if you use different compilers). You do of course lose the features of the DLL architecture, such as run-time loading of functions, but this can be a small price to pay in many cases.

Answer 5

If you use a DLL make initialization of all objects at event "DLL PROCESS ATTACH" and export a pointer to its classes/objects.
You may provide specific functions to create and destroy objects and functions to obtain the pointer of the objects created, so you can encapsulate these calls in a wrapper class of access at include file.

Answer 6

The best way I found to handle this scenario is:

create your library, naming it with the compiler and stl versions included in the library name, exactly like boost libraries do.

examples:

- FontManager-msvc10-mt.dll for dll version, specific for MSVC10 compiler, with the default stl.

- FontManager-msvc10_stlport-mt.dll for dll version, specific for MSVC10 compiler, with the stl port.

- FontManager-msvc9-mt.dll for dll version, specific for MSVC 2008 compiler, with the default stl

- libFontManager-msvc10-mt.lib for static lib version, specific for MSVC10 compiler, with the default stl.

following this pattern, you will avoid problems related with different stl implementations. remember, the stl implementation in vc2008 differs from the stl implementation in the vc2010.

See your example using boost::config library:

#include <boost/config.hpp>

#ifdef BOOST_MSVC
#  pragma warning( push )
#  pragma warning( disable: 4251 )
#endif

class DLL_EXPORT FontManager
{
public:
   std::map<int, std::string> int2string_map;
}

#ifdef BOOST_MSVC
#  pragma warning( pop )
#endif