解决 Warning C4251 问题

查到一片不错的英文资料：http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html

 

Microsoft Visual Studio .NET 2003 Warning C4251

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<_Ty>' needs to 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' needs to 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. Youalso 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 exportdefinitions, not declarations, and a template is not a definition. It's code is only created when you create aninstantiation. 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 codedoes not produce any errors!. It works just fine! I think this is a case where something works even though it shouldn't. SomeTemplate isnot 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 adeclaration only, and a declaration cannot be exported because there is no actual code to back it up. However, SomeTemplate is adefinition, 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 calledexplicit 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<_Ty>' 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 variablesinside 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::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 itis 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 >; #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, \ std::allocator,false> > >; \ template class dllmacro std::allocator< \ std::_Tree_ptr, \ std::allocator,false> > >; \ template class dllmacro std::_Tree_ptr< \ std::_Tset_traits, \ std::allocator,false> >; \ template class dllmacro std::_Tree_nod< \ std::_Tset_traits, \ std::allocator,false> >; \ template class dllmacro std::_Tree_val< \ std::_Tset_traits, \ std::allocator,false> >; \ template class dllmacro std::set< settype, std::less< settype >, \ std::allocator< settype > >; #define EXPORT_STL_MAP( dllmacro, mapkey, mapvalue ) \ template struct dllmacro std::pair< mapkey,mapvalue >; \ template class dllmacro std::allocator< \ std::pair >; \ template struct dllmacro std::less< mapkey >; \ template class dllmacro std::allocator< \ std::_Tree_ptr, \ std::allocator >,false> > >; \ template class dllmacro std::allocator< \ std::_Tree_nod, \ std::allocator >,false> > >; \ template class dllmacro std::_Tree_nod< \ std::_Tmap_traits, \ std::allocator >,false> >; \ template class dllmacro std::_Tree_ptr< \ std::_Tmap_traits, \ std::allocator >,false> >; \ template class dllmacro std::_Tree_val< \ std::_Tmap_traits, \ std::allocator >,false> >; \ template class dllmacro std::map< \ mapkey, mapvalue, std::less< mapkey >, \ std::allocator > >; Yea. Ugly. Soooo ugly. All this just to get rid of some warnings. And I've got bad news....

Workaround 2 can cause link errors...

That's right. Fixing warning C4251 for templates can cause multiply-defined symbol errors. Say you have some DLL with an exported class containing a std::vector that you have explicitly instantiated and exported as shown above. Your C4251 warnings are fixed. Nice! But then you want to use another DLL that has an exported class containing a std::vector with the same explicit-instantiation workaround. Trouble... When you try to link to both DLLs at the same time, you will get multiply-defined symbol errors! Both DLLs contain a specific class called std::vector. They each have a copy of the symbols generated during template instantiation. The linker has no idea that the symbols are the same because the underlying code is the same, because it's in the compiled DLLs that it doesn't have access to. So it spits out link errors.... This is monumentally frustrating, in my opinion. As far as I can see the only real option here is to disable the warning and ignore it. You simply cannot use std::vector for simple types in classes exported from DLLs without at least generating warnings. One thing that should work but doesn't is to make your vector private and not use it in inline functions. According to the documentation snippet shown above, this should be ok. It is not accesible to clients of the DLL. But the warning still comes up. Another very unappealing option is to create a DLL where you explicitly instantiate all the STL classes you want ot use (vector, map, and so on) and wrap each of them, and then use the wrappers everywhere in your DLL interfaces. The wrappers are easy to write, just subclass the type you want (ie IntVector : public std::vector) and do the explicit instantiation trick above the class definition. But you'll have to write constructors too, and you'll have to do this for each pair of stl container / datatype you want to use in your DLL interfaces. Seems like a lot of work to me....

Microsoft to the Rescue! (....well....sort of....)

Microsoft has (recently?) added a knowledge base article about this problem. Here is a link to the article: How To Exporting STL Components Inside & Outside of a Class (Yes. That is really the title. You would think someone checked at least the titles for grammar...) Anyway, the gist of this article is that you cannot export anything except std::vector. I have not studied it extensively. It might deal with the link errors I mentioned before - but only for vectors. Yes, only for vectors. This KB article says that all other classes contain internal classes which cannot be exported. Which, I guess, means that those macros above onlyhide the warnings, but don't actually change the export behavior. Which might explain the link errors I have seen (they were all for vector!). Anyway, I'm still just hiding the warning with a pragma...

Conclusion

Disable the warning? You can do it locally and cleanly using pragma warning (push : XXXX) and (pop : XXXX) around your disable pragma, check the docs for pragma warning. You shouldn't just blindly disable the warning for anyone else who includes your header, because maybe they want that warning turned on. And if you are shipping a DLL to someone else, you probably want to be certain that all the non-template classes you want to export are marked as such. In this case disabling the warning might not be such a good idea... I have no idea what the "right" behavior is here. It would be nice if we could say that the link error is wrong, but it's not. The linker has two different DLLs with the same symbols. It would bespace madness for the linker to assume that it was the same code. Warning C4251 isn't really wrong either. Your template instantiation is not exported. I suppose if you compiled the DLL with VC6 and the calling code with VC7 you might get some differences in the template instantiation name mangling or something that would cause link errors. Or even worse, the name mangling would be the same but the instantiation memory alignment would be slightly different or something. You could get crashes in that case. Note: It seems that the above situation has occurred, between Visual Studio 7 and 8. Loren Meck writes "the predicted crashes do indeed happen when linking VC7 executables that use std::vector with VC8 executables that also use std::vector ". So, that's bad....very, very bad.... So the warning does have a purpose. But even with the explicit instantiation, I'm not certain the calling code is actually using it. This just seems to be one of the many C++ template inconsistencies that we just have to live with. Or switch to C#, I guess....

 

另一篇中文解决方案：http://hi.baidu.com/_%E2d_%B7%B3_%DE%B2%C2%D2/blog/item/a69368fa45782715a9d311c1.html#0

 这通常是由于以数据成员方式在DLL导出类中使用了模板类造成的。比如：
#include
#include
using namespace std;

class __declspec( dllexport ) Test
{
public:
std::vector m_objCon;
};

int main()
{


return 0;
}

这会导致这个警告:
warning C4251: “Test::m_objCon”: class“std::vector<_Ty>”需要有 dll 接口由 class“Test”的客户端使用
1>        with
1>        [
1>            _Ty=int
1>        ]
这个问题主要要描述的是不同的地方的vector的实现可能不一样所造成的问题。所以我们应该将其导出。有很多方法可以解决这个问题的。

第一种： 无视它或者#pragma warnind( disable: 4251 )
第二种：将该数据改为指针方式：
class __declspec( dllexport ) Test
{
public:
std::vector* m_objCon;
};
然后在构造函数和析构函数中分别初始化和释放它。
第三种：
将该模板类及其依赖类导出。
#include
#include
using namespace std;

class __declspec( dllexport ) Test
{
public:
template  class __declspec( dllexport ) std::allocator;
template  class __declspec( dllexport ) std::vector >;
public:

std::vector m_objCon;
};

int main()
{


return 0;
}
这种方法要注意的是必须要把要导出模板类的模板数据成员一并导出。有点类似于显式实例化。比如说你要导出boost::shared_ptr就还必须将其依赖的shared_count一并导出。导出map还需要导出对应pair等等。很麻烦啦~所以我们还是选择第四种吧。

第四种：Impl。
#include
#include
using namespace std;

// 这些放到.h中
class Test_imp;
class __declspec( dllexport ) Test
{
// 构造函数中初始化 析构中释放m_pImp;
void test();
public:
Test_imp* m_pImp;
};

// 这个类放到cpp中去
class  Test_imp
{
public:
void test(){}
std::vector m_objCon;
};

// 放到cpp中
void Test::test()
{
m_pImp->test();
}

int main()
{


return 0;
}

个人推荐第二种和第四种，反对第一种。毕竟掩耳盗铃不是好习惯~~
第四种除了可以解决上面的问题之外还可以隐藏代码，当然多了一个桥接的过程。关于这个东西可以看看我08年的时候写的一篇垃圾文章，也许有帮助：这里
那时候比现在还菜，所以乱七八糟的，凑合看看吧~(比如说导出类的时候每个函数都去加_declspec(dllexport)，那是一个悲剧，不要学哦~)

另外，如果上面的方法解决不到你的问题，你可以回帖或者看看这个：
点我