vs2008 warning C4251
要将一个class封装成dll，遇到warning C4251: class 'std::vector' needs to have dll-interface to be used by clients o...，在网上查到这个，解决问题，非常详细。
转自： http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html
I always try to get rid of compiler warnings. It just seems like a good thing to do. Warning-free code makes me happy. But some warnings just don't want to go away, and this is one of them. I use STL frequently, and my own templates from time to time, and every time I try to turn some code with templates into a DLL I inevitably end up with hundreds of warnings that look like this:
warning C4251: 'AClass::m_vector' : class std::vector' needsto have dll-interface to be used by clients of class 'AClass'
This happens with my own non-STL template classes too:
warning C4251: 'AClass::m_variable' : class 'SomeTemplate' needsto have dll-interface to be used by clients of class 'AClass'
I'm going to explain why I think this warning happens, and what you can do to get rid of it. If you read something below that you think is wrong, please let me know. I am by no means an expert. This is just what I've figured out so far, and I'm as much making notes for myself as anything...
WTF?
I'm going to assume that you are familiar with using __declspec( dllexport ) and __declspec( dllimport ). If not, look it up in the VC++ documentation. I'll assume that you have a macro DLLImportExportMacro that exports or imports conditionally. If you don't know what I'm talking about, just create a Win32 DLL project and look at hte top of the DLLName.h header that is auto-generated.
Anyway, if you mark some class AClass in a DLL as exportable with dllexport, then you have access to that class whenever you import the DLL. You also have access to various internals of that class - superclasses, protected internals (because you can subclass AClass), and anything that is used in inline functions of X (because they are compiled in your importing code, so they have to be exported).
In fact, the documentation explicitly states this in the page titled "Using dllimport and dllexport in C++ Classes" :
As a rule, everything that is accessible to the DLL's client (according to C++ access rules) should be part of the exportable interface. This includes private data members referenced in inline functions
This is the problem. If you have a template SomeTemplate, it is not marked with dllexport because you can only export definitions, not declarations, and a template is not a definition. It's code is only created when you create an instantiation. So when you have this:
class DLLImportExportMacro AClass
{
public:
SomeTemplate GetVariable() { return y; }
protected:
SomeTemplate y;
};
Then SomeTemplate is an instantiation of SomeTemplate that is accesible to clients of AClass but is not exported!
Now, if AClass was not exported and you tried to use it in some importing code, you would get link errors. And if you replace SomeTemplate with a non-template non-exported class, and try to call the GetVariable() function in some importing code, you will again get link errors. But calling GetVariable() as defined above in importing code does not produce any errors!. It works just fine!
I think this is a case where something works even though it shouldn't. SomeTemplate is not exported. So the warning is not incorrect. But in calling code, whenever you might use SomeTemplate, the compiler is going to automatically instantiate SomeTemplate, creating a local version of SomeTemplate. They are the same code, so all the same symbols are defined, and there are no link errors. I guess we could call this "implicit exporting" - the header for SomeTemplate is necessarily exported, and the template instantiation mechanism implicitly imports it by re-generating the code locally.
I suppose it's possible that you might have compiled the DLL containing AClass with different flags or something. In that case you might be able to get a link error. I haven't tried this...
Workaround 1 - Disable the Warning
Ok, so this warning is a nuisance and you want it to go away. One option is to simply disable it. Just put the following code at the bottom of some header that is included before any of the DLL headers (stdafx.h works well for me....):
#pragma warning( disable: 4251 )
This will get rid of your warnings. But in the previous section I noted that there are cases where this warning does tell you something important (when SomeTemplate is replaced by a non-exported non-template class). In that case you will get link errors if you try to access this class from the importing code. So the warning is helpful there.
Of course, it does mean you have to scour the 4251 warnings to see if there is any non-template stuff in there. If you are the only one using your DLL, you'll find out about the link errors soon enough. So maybe disabling is the best option...
I'm going to explain another workaround, but I'll warn you right now that it doesn't work all the time, particularly for STL.
Workaround 2 - Explicit Template Instantiation
Lets look at this code again:
class DLLImportExportMacro AClass
{
public:
SomeTemplate GetVariable() { return y; }
protected:
SomeTemplate y;
};
Warning C4251 pops up because SomeTemplate is not exported. Now ideally we would export SomeTemplate and all it's instantiations would be exported, but that only works in fantasy land. In reality, SomeTemplate is a declaration only, and a declaration cannot be exported because there is no actual code to back it up. However, SomeTemplate is a definition, not a declaration, so we can export it. We simply have to mark the instantiation with DLLImportExportMacro. Sounds easy, but since the instantiation is automatically done by the header how the hell are you supposed to mark it with a macro?
Well, you have to beat the compiler to the punch and instantiate the template yourself. This is called explicit instantiation and is simple to do. Here is what you would do for the above example:
class DLLImportExportMacro AClass
{
public:
SomeTemplate GetVariable() { return y; }
protected:
template class DLLImportExportMacro SomeTemplate;
SomeTemplate y;
};
That "template class ..." bit is the explicit instantiation, and we throw your DLL import/export macro in there so that the explicit instantiation is exported. This will shut up the compiler and clear up the C4251 warning. But note that it has no actual effect on the running of your code - it will have worked before. This just avoids the warning.
Workaround 2 For STL
So far I've been working with your hypothetical template class SomeTemplate. Now let's consider the case where SomeTemplate is in fact std::vector:
class DLLImportExportMacro AClass
{
public:
std::vector GetVariable() { return y; }
protected:
template class DLLImportExportMacro std::vector;
std::vector y;
};
This seems easy, right? But it doesn't work. Now you are going to get something like this:
warning C4251: 'std::_Vector_val<_Ty,_Alloc>::_Alval' :
class std::allocator' needs to have dll-interface to be used by clients of class 'std::_Vector_val<_Ty,_Alloc>'
Which will be frustrating. This is because while we all use "std::vector", the actual class definition has a default template parameter defining the allocator, "std::vector". This whole exporting thing cascades to variables inside the templates you want to export. So you have to export the allocator too, and export the full vector template definition:
class DLLImportExportMacro AClass
{
public:
std::vector GetVariable() { return y; }
protected:
template class DLLImportExportMacro std::allocator
template class DLLImportExportMacro std::vector
std::allocator >;
std::vector y;
};
If you do this, then the C4251 warning will go away. Hurray! Again, no effect on the actual execution of your code. Just avoiding a warning.
Note that this cascading can happen for your own templates too. And there is one case where it is important - when your template SomeTemplate contains a non-template class object that is not exported. In this case, you have to export that class or you will get link errors.
Workaround 2 for Other STL Classes
We saw above that we also had to export the allocator for std::vector to get the warnings to stop. How about for other STL classes? You had to ask. I've only needed to do this for std::set and std::map, so those are the two I will show. Understand that internally these classes are quite a bit more complicated than std::vector. I'm going to present all 3 (vector, set, and map) as macros that you can cut and paste. Here goes:
Note: In these macros you need to replace 'dllmacro' with whatever your import/export macro is
#define EXPORT_STL_VECTOR( dllmacro, vectype ) /
template class dllmacro std::allocator< vectype >; /
template class dllmacro std::vector
std::allocator< vectype > >;
#define EXPORT_STL_SET( dllmacro, settype ) /
template class dllmacro std::allocator< settype >; /
template struct dllmacro std::less< settype >; /
template class dllmacro std::allocator< /
std::_Tree_nod