![](/img/trans.png)
[英]Why does MSVC (Visual C++) need separate dllimport and dllexport attributes and gcc not?
[英]Will c++1z modules replace the need for dllimport dllexport on windows
我正在学习 C++1z 的模块建议。 我最大的希望是它将取代 Windows 上dllimport
、 dllexport
的使用。 使用 c++1z 模块,我是否能够在 windows 上构建.dll
并在 linux 上构建.so
避免使用dllimport/dllexport
? 模块export
是所有平台和编译器都需要的吗?
不幸的是,没有。
C++ 中的模块建议试图解决头文件中的缺点,这对于涉及头文件的代码尤其成问题。
模板通常完全在标头中实现——但这意味着模板的内容受制于在包含该标头之前发生的任何预处理器定义。
例如,如果您的模板使用i
作为标识符,并且在模板的标头之前恰好包含了一个类似#define i 2
的标头,则您的代码可能如下所示:
for (int i=0; i<10 ; i++)
...但是在预处理器完成后,它看起来像这样:
for (int 2=0; 2<20; 2++)
...显然根本无法编译。
模块解决了这个问题。 模块是独立编译的,而不是在头文件中。 由于它是独立编译的,模块不受其他头文件的影响,除非其源代码包含这些头文件。
同样,在头文件中进行的任何预处理器定义都不能影响导入模块的任何代码。 模块中唯一在导入该模块的文件中可见的名称是从模块显式导出的名称。
仍然需要 dllexport,但 dllimport 可能是自动的。 至少在VS 2015 Update 1中的C++ 模块中,他们在一条评论中说:
安德鲁·帕多 [微软]
@Matthias:程序员现在只需要为要在 DLL 边界导出的符号说 __declspec(dllexport)。 __declspec(dllimport) 在使用模块时由编译器处理。
不幸的是,我没有找到关于它的任何更可靠的信息。
可能。
我阅读了提交给标准委员会的 c++20 提案——它们现在在 GitHub 上——并且有一个可以涵盖这一点。 它提出了一个新的 [[shared]] c++ 属性来实现这一点,并且强制要求像 GCC 和 MSVC 这样的编译器来实现它。 不幸的是,它可能错过了进入 c++20 规范的窗口,尽管他们仍有时间在最后一刻批准它。
我个人希望他们说“确定”并及时添加。 这个属性语法的全部意义——以及这些其他语言变化的一半——据说使我们能够在正常代码中停止需要宏和供应商特定的样板。 比如说,就像构建一个 DLL。 所以如果他们不采纳这个提议,他们最终将不得不采纳类似的东西。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.