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

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

非常感谢你的答复。

有帮助吗?

解决方案

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

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

其他提示

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

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

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

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top