Exporting classes containing `std::` objects (vector, map etc.) from a DLL

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 really 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?

Agleam

Recommended related reading: https://mcmap.net/q/176873/-can-i-pass-std-string-to-a-dll/103167 – Afoul

Answer 1

When you touch a member in your class from the client, you need to provide a DLL-interface. A DLL-interface means, that the compiler creates the function in the DLL itself and makes it importable.

Because the compiler doesn't know which methods are used by the clients of a DLL_EXPORTED class it must enforce that all methods are dll-exported. It must enforce that all members which can be accessed by clients must dll-export their functions too. This happens when the compiler is warning you of methods not exported and the linker of the client sending errors.

Not every member must be marked with with dll-export, e.g. private members not touchable by clients. Here you can ignore/disable the warnings (beware of compiler generated dtor/ctors).

Otherwise the members must export their methods. Forward declaring them with DLL_EXPORT does not export the methods of these classes. You have to mark the according classes in their compilation-unit as DLL_EXPORT.

What it boils down to ... (for not dll-exportable members)

1. If you have members which aren't/can't be used by clients, switch off the warning.

2. If you have members which must be used by clients, create a dll-export wrapper or create indirection methods.

3. To cut down the count of externally visible members, use approaches such as the PIMPL idiom.

---

template class DLL_EXPORT std::allocator<tCharGlyphProviderRef>;

This does create an instantiation of the template specialization in the current compilation unit. So this creates the methods of std::allocator in the dll and exports the corresponding methods. This does not work for concrete classes as this is only an instantiation of template classes.

Ineradicable

Thanks Chris - in this case there's the additional issue that those are standard containers that are header only - so I'm not sure we'd need the functions to be called through the dll on those members as long as those functions are identical in both the client and the dll - long story short mine are NOT exposed to the clients directly so I will disable the warnings :) - but are you sure it would hurt to disable them even if they were exposed given the circumstances? – Agleam

Btw - there's one problem with defining that classes are private so they can not be touched - this does not take into account copying/creating/destroying of those objects - so we can say that we can disable the warning only if those operations are not directly possible for the client on our main object. In this case though I'm almost sure we don't have any problem at all as the functions are available to the client just as they are to the dll - through the compilers standard headers - right? :) – Agleam

I think template classes may not expose these problems, because the methods get instantiated in the clients implementation modules. This does also work for inline functions. But I don't know if all problems go away with that, because some templates call non-templated code (e.g. std::exception::what). – Ineradicable

"this does not take into account copying/creating/destroying" yes, as mentioned. But declaring these operations does circumvent the problems. – Ineradicable

Answer 2

That warning is telling you that users of your DLL will not have access to your container member variables across the DLL boundary. Explicitly exporting them makes them available, but is it a good idea?

In general, I'd avoid exporting std containers from your DLL. If you can absolutely guarantee your DLL will be used with the same runtime and compiler version you'd be safe. You must ensure memory allocated in your DLL is deallocated using the same memory manager. To do otherwise will, at best, assert at runtime.

So, don't expose containers directly across DLL boundaries. If you need to expose container elements, do so via accessor methods. In the case you provided, separate the interface from the implementation and expose the inteface at the DLL level. Your use of std containers is an implementation detail that the client of your DLL shouldn't need to access.

Alternatively, do what Neil suggest and create a static library instead of a DLL. You lose the ability to load the library at runtime, and consumers of your library must relink anytime you change your library. If these are compromises you can live with, a static library would at least get you past this problem. I'll still argue you're exposing implementation details unnecessarily but it might make sense for your particular library.

Eckstein

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.

Loudmouth

Thanks for the details - personally I always preferred STLPort and now I'll have another reason for it :D – Agleam

Answer 4

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

Devolve

Answer 5

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.

Welby

You really can't mix compilers anyway, if your DLL interface uses C++ classes - especially if you're using standard library types. – Gujarati

There's always a number of ways to skin a cat and if this is an option I agree it should be taken. – Agleam

Answer 6

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

Lathy

Thanks Chris - it's really a gread article and basically sums up this thread nicely - looks we ( disable it and assume compile environment compatibility between clients and the dll OR use lib's and not dll's OR don't use templates in exported classes ) AND none of the above seem right :( – Agleam

Answer 7

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

Thorn

This is in fact the best practice I have come to use when designing my interfaces with the biggest additional benefit being that we're also not creating a dependency between the modules and each of them is free to use any container library they wish. – Agleam

Answer 8

In such cases, consider the uses of the pimpl idiom. Hide all the complex types behind a single void*. Compiler typically fails to notice that your members are private and all methods included in the DLL.

Gujarati

Answer 9

none of the workarounds above are acceptable with MSVC because of the static data members inside template classes like stl containers

each module (dll/exe) gets its own copy of each static definition...wow! this will lead to terrible things if you somehow 'export' such data (as 'pointed' above)...so don't try this at home

see http://support.microsoft.com/kb/172396/en-us

Capitalist

I'd love to know more on how to actually solve things, but your link is dead – Marie

old problem, old link.... Anyway, here's a copy I believe: jeffpar.github.io/kbarchive/kb/172/Q172396. In my case the problem was exactly the one described in the article: std::vector had internal statics, each module (dll/exe) got a different instance for those statics which led to a malfunctioning std::vector when exposed as public member of a dll class. Note that: I am not sure this is still the case with current stl/compilers, I had this issue 12 years ago... ps: I think that what I did was to make the std::vector member private and only expose methods for accessing it. – Capitalist

not sure if I had a std::vector or a std::map. Anyway, it's probably best to encapsulate both. – Capitalist

Not an old problem; people face it everyday. Thanks for updating the answer! I do think that article is the best I've seen to date. – Marie

Answer 10

Exporting classes containing std:: objects (vector, map, etc) from a dll

Also see Microsoft's KB 168958 article 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. From the article:

To Export an STL Class

1. In both the DLL and the .exe file, link with the same DLL version of the C run time. Either link both with Msvcrt.lib (release build) or link both with Msvcrtd.lib (debug build).
2. In the DLL, provide the __declspec specifier in the template instantiation declaration to export the STL class instantiation from the DLL.
3. In the .exe file, provide the extern and __declspec specifiers in the template instantiation declaration to import the class from the DLL. This results in a warning C4231 "nonstandard extension used : 'extern' before template explicit instantiation." You can ignore this warning.

And:

To Export a Class Containing a Data Member that Is an STL Object

1. In both the DLL and the .exe file, link with the same DLL version of the C run time. Either link both with Msvcrt.lib (release build) or link both with Msvcrtd.lib (debug build).
2. In the DLL, provide the __declspec specifier in the template instantiation declaration to export the STL class instantiation from the DLL.
   
   NOTE: You cannot skip step 2. You must export the instantiation of the STL class that you use to create the data member.
3. In the DLL, provide the __declspec specifier in the declaration of the class to export the class from the DLL.
4. In the .exe file, provide the __declspec specifier in the declaration of the class to import the class from the DLL. If the class you are exporting has one or more base classes, then you must export the base classes as well.
   
   If the class you are exporting contains data members that are of class type, then you must export the classes of the data members as well.

Baily

Answer 11

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.

Unchain

Answer 12

The best approach to use in such scenarios is to use the PIMPL design pattern.

Jetblack