导出数据成员是否正确?(C++）

C++类意味着DLL客户端由于名称重整和其他问题而必须使用与DLL相同的编译器。这实际上是一个相当大的问题，我曾经不得不将 C 包装器写入一堆 C++ 类，因为客户端程序已切换到 MSVC9，而 DLL 本身使用的是 MSVC71。[将 DLL 切换到 MSVC90 还有其他一些复杂问题]。从那以后，我一直对导出类的业务持怀疑态度，并且更喜欢为所有内容编写 C 包装器。

现在，如果您愿意为导出类付出代价，我会说导出静态数据不会使问题变得更糟。可以说，在可以导出的东西中，导出静态常量是最安全的。即便如此，我宁愿不这样做，因为就像 Timo 说的那样，你现在被锁定在这个实现中。

我使用的一个框架要求其客户端提供一组错误代码常量。随着时间的推移，我们发现使用一堆简单的常量太脆弱了，我们改用了 OO 设计。我们有一个默认实现，它将返回常见的错误代码，但是每个错误代码都是使用虚拟函数访问的，该函数可以被单个客户端覆盖 - 他们从一些高级设备特定的错误处理中使用它。事实证明，此解决方案比基于导出常量的解决方案更具可扩展性。

我建议您在导出静态变量之前仔细考虑一下您希望组件如何演变。

它是否正确，因为它可以工作并做你期望的事情？假设您正在谈论在类或类成员上使用_declspec（dllexport/dllimport），是的，您可以这样做，它应该会给您预期的结果 - 静态数据可以在您的 dll 之外访问，其他C++代码可以访问它，前提是C++访问规范（公共/受保护/私有）首先不会阻止外部访问。

这是个好主意吗？我个人不这么认为，因为您不仅会在库内公开类内部，还会向外部世界公开类内部，这意味着在一天结束时几乎不可能更改什么是实现细节。问问自己，你是否100%确定这个类的接口及其大部分实现是否永远不会改变......

的（非静态）数据成员上的dllexport（或import）不执行任何操作。 导出的"事物"要么是函数，要么是全局数据（尽管这是一个有问题的设计选择）。 类上的 dllexport 只是说"导出所有这些函数"的快捷方式。