导出数据成员是否正确？ （C++）

Question

正如标题所示，从C++类中导入/导出静态数据是正确还是有效的？

我发现我的问题 - 我正在看的类的作者试图导出此平台上不支持的可写静态数据。

但非常感谢您的回应。

Answer 1

它是否正确，因为它会起作用并做你期望的事情？假设你正在讨论在类或类成员上使用_declspec（dllexport/dllimport），是的，你可以这样做，它应该给你预期的结果 - 静态数据可以在你的dll之外访问，其他C++代码可以访问它规定C++访问规范（public/protected/private）不会首先阻止外部访问。

这是一个好主意吗？就我个人而言，我不这么认为，因为您不仅会在图书馆内向外部世界揭露课程内部，这意味着在一天结束时改变实施细节几乎是不可能的。问问你自己，如果你是100％确定，如果这个类的接口和它的大部分实现将永远不会改变...

Answer 2

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

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

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

我建议您在输出静态变量之前认真考虑组件的演变情况。

Answer 3

类的（非静态）数据成员上的dllexport（或导入）不执行任何操作。导出的“事物”是功能或全局数据（尽管这是一个值得怀疑的设计选择）。类上的dllexport只是一个说“导出所有这些函数”的快捷方式。