正如标题所示，从 C++ 类中导入/导出静态数据是否正确或有效？
我发现了我的问题 - 我正在查看的课程的作者试图导出此平台不支持的可写静态数据。
非常感谢您的回复。
【问题讨论】：
导出的 C++ 类意味着 DLL 客户端必须使用与 DLL 相同的编译器，因为名称修改和其他问题。这实际上是一个相当大的问题，我曾经不得不为一堆 C++ 类编写 C 包装器，因为客户端程序已经切换到 MSVC9，而 DLL 本身使用的是 MSVC71。 [将 DLL 切换到 MSVC90 还存在一些其他问题]。从那以后，我一直对导出类的业务持怀疑态度，并且更喜欢为所有内容编写 C 包装器。
现在，如果您愿意为导出类付出代价，我想说导出静态数据不会让问题变得更糟。可以说，在您可以导出的各种东西中，导出静态常量是最安全的。即便如此，我宁愿不这样做，因为就像 Timo 所说，你现在被锁定在这个实现中。
我从事的一个框架要求其客户提供一组错误代码常量。随着时间的推移，我们发现使用一堆简单的常量太脆弱了，我们切换到了 OO 设计。我们有一个默认实现，它会返回常见的错误代码，但是每个错误代码都是使用一个虚拟函数来访问的，该虚拟函数可以被单个客户端覆盖——他们从一些高级设备特定的错误处理中使用它。事实证明，该解决方案远比基于导出常量的解决方案更具可扩展性。
我建议您在导出静态变量之前仔细考虑一下您期望组件如何发展。
【讨论】：
它是否正确，因为它可以工作并按照您的期望进行？假设您正在谈论在类或类成员上使用 _declspec(dllexport/dllimport)，是的，您可以这样做，它应该会给您预期的结果 - 静态数据可以在您的 dll 之外访问，其他 C++ 代码可以访问它规定 C++ 访问规范（公共/受保护/私有）首先不会阻止外部访问。
这是个好主意吗？就我个人而言，我不这么认为，因为您不仅会在您的库中而且向外部世界公开类内部结构，这意味着在一天结束时更改实现细节几乎是不可能的。问问自己，你是否 100% 确定这个类的接口和它的大部分实现永远不会改变......
【讨论】：
类的（非静态）数据成员上的 dllexport（或导入）什么都不做。导出的“事物”要么是函数，要么是全局数据（尽管这是一个值得商榷的设计选择）。类上的 dllexport 只是说“导出所有这些函数”的快捷方式。
【讨论】：