为何Visual Studio需dllimport与dllexport，而GCC仅用visibility关键字？

首先给出将默认可见性设为hidden的跨平台共享库常见实现代码：

#if defined _WIN32
  #ifdef BUILDING_DLL
    #define DLL_PUBLIC __declspec(dllexport)
  #else
    #define DLL_PUBLIC __declspec(dllimport)
  #endif
#else
  #define DLL_PUBLIC __attribute__ ((visibility ("default")))
#endif

针对核心问题「为何Visual Studio编译/使用共享库需要两个关键字，而GNU编译器仅需一个」，结合相关疑问逐一解答：

1. 两种实现是否等价，存在哪些陷阱？ #

这两种实现并非完全等价，核心差异和陷阱如下：

• Visual Studio侧：dllexport和dllimport是分工明确的指令：编译共享库时用dllexport，会触发编译器标记符号为导出项，链接器生成DLL的同时会生成对应的导入库（.lib）；使用共享库时用dllimport，会告诉编译器该符号来自DLL的导入地址表（IAT），生成间接调用代码以减少运行时重定位开销。如果用错关键字，比如编译库时用dllimport，会导致符号无法导出；使用库时用dllexport，可能出现符号重复定义或链接失败的问题。
• GCC侧：__attribute__((visibility("default")))是统一的符号可见性标记，不管是编译共享库还是使用库，作用都是将目标符号设为对外可见（当全局默认可见性设为hidden时）。GCC在使用共享库时不需要特殊标记，只要链接阶段指定正确的共享库文件即可。
• 跨平台陷阱：Windows默认会导出所有未标记__declspec(hidden)的符号，而Linux下如果开启-fvisibility=hidden，只有标记了visibility("default")的符号才会导出。如果忽略这个差异，可能导致Linux下部分符号意外隐藏，或者Windows下导出过多不必要的符号。

2. Visual Studio用双关键字是否仅因历史原因？ #

有历史因素，但不全是。早期Windows的DLL机制设计时，就将导出和导入拆分为两个独立流程，依赖导入库（.lib）完成符号链接，这种设计延续至今。不过更关键的是，Windows链接器的工作逻辑需要明确区分「导出符号」和「导入符号」，才能正确生成DLL的导出表和对应的导入库，并非单纯的历史包袱。

3. 内部技术差异是否导致Visual Studio必须用双关键字？ #

是的，核心源于两种平台的二进制格式和链接机制差异：

• Windows PE格式（DLL基于PE）：PE文件的导出符号需要在专门的导出表中声明，dllexport会让编译器在目标文件中标记符号为导出项，链接器生成DLL时会构建导出表，同时生成导入库（.lib）——这个导入库包含了符号对应的导入地址信息。而dllimport会告诉编译器，该符号来自外部DLL的导入地址表，编译时生成针对IAT的间接调用指令，避免运行时重定位的性能损耗，同时链接阶段会自动关联对应的导入库。
• GNU ELF格式：ELF共享库的符号可见性是通过编译属性直接控制的，visibility("default")仅用于标记符号对外可见，编译共享库时会将这些符号加入动态符号表；使用共享库时，动态链接器会在运行时直接从共享库的动态符号表中解析符号，不需要单独的导入库（即便有静态导入库，也只是共享库的链接代理，并非必需）。因此GCC不需要区分导出/导入的关键字，一个可见性标记即可覆盖两种场景。

内容的提问来源于stack exchange，提问作者mastov