c++ - 我们可以忽略 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 使用文本值初始化字符串。
• Derived 会尝试更改字符串。
• 它会尝试释放字符串的堆内存。

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

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

DLL 类接口(interface)无疑是有史以来最糟糕的想法。

仅有的 2 项豁免是:

• 你用的是DCOM(或者纯抽象类，思路一样)
• 您可以控制整个代码树。例如，dll 和 exe 是在同一个解决方案中构建的。

在所有其他情况下，DLL 类接口(interface)都是噩梦，灾难等待发生。

我认为this thread可能会建议您解决方案。

如果您使用相同的编译器编译所有内容并使用 /MD 以便所有模块共享相同的运行时，请随意忽略 C4275。