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

Question

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

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

非常感谢你的答复。

Answer 1

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

现在，如果您愿意为出口类付出代价，我会说导出静态数据并不会让问题变得更糟。可以说，在您可以导出的各种事物中，最安全的是导出静态常量。即使这样，我也不愿意这样做，因为像Timo说的那样，你现在已经陷入了这种实施中。

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

我建议您在导出静态变量之前，仔细考虑如何期望组件发展。

Answer 2

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

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

Answer 3

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