我们可以忽略MySQL ++ C4275警告吗？

Question

c:\program files\microsoft visual studio 9.0\vc\include\result.h(212) : warning C4275: non dll-interface class 'std::_Container_base_aux' used as base for dll-interface class 'std::_Container_base_aux_alloc_real<_Alloc>' 
1>  with 
1>  [ 
1>   _Alloc=std::allocator<mysqlpp::Row> 
1>  ] 
1>  C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xutility(377) : see declaration of 'std::_Container_base_aux' 

这可能是与容器相关的任何问题的原因，还是可以在Visual Studio 2008中安全地忽略它？

Answer 1

在这种情况下，我认为这取决于std :: runtime_error。为了让客户端使用这个类，它必须使用客户端提供的定义，而不是DLL端。为了成功，客户端编译器应该与DLL编译器的版本完全相同。

除了类定义不能跨模块边界移植的事实之外，还有内存所有权要考虑。

如果您从具有类似std :: string的内部变量的类派生出来，那将是一场等待发生的灾难。如果dll会使用另一个类从中导出的另一个运行时，则可能发生以下情况：

• Base使用文本值初始化字符串。
• 派生会尝试更改字符串。
• 它会尝试释放字符串的堆内存。

这当然不限于字符串。这只是一个例子。任何情况下，1运行时分配的东西，另一个释放它会导致崩溃。

堆内存由基类使用的运行时所拥有。派生类的Thr运行时试图释放它 - >即时崩溃。为了给你一个使用相同C++编译器编译的dll，并使用相同的运行时，你将受到dll提供者的支配。这是一个维护噩梦。

DLL类接口无疑是有史以来最糟糕的想法。只有2

的豁免是：

• 使用DCOM（或纯抽象类，这是相同的想法）
• 你在整个码树的控制。例如，dll和exe是在同一个解决方案中构建的。

在所有其他情况下，DLL类接口支持恶梦和等待发生的灾难。

我认为this thread 可能会建议你一个解决方案。

如果使用相同的编译器编译所有内容并使用/MD，那么可以忽略C4275，因此所有模块共享相同的运行时。