我应该在 DLL 导出函数上使用 __stdcall 吗？答案

【问题标题】：Should I use __stdcall on DLL export functions?我应该在 DLL 导出函数上使用 __stdcall 吗？
【发布时间】：2019-02-28 12:42:57
【问题描述】：

我正在使用 mingw-w64 用 C 语言编写一个小 DLL，它应该可以被 VB.net 程序调用。唯一的导出是其参数和返回类型都是原始类型的函数。

我是否应该在dllexport 函数上使用__stdcall？

在网上搜索时，我看到了有和没有它的例子。有关于它如何影响名称修饰的讨论，但没有关于这是否是一件好事以及对我的 DLL 可用性有什么影响的建议。

【问题讨论】：

接下来的问题 - 你可以使用来自 VB.net 的不同调用约定吗？例如，您可以将导出的函数调用（声明）为 __fastcall 或 __cdecl 吗？如果可以 - 您可以使用任何调用约定。如果说 VB.net 只能调用 __stdcall 外部 api - 您当然需要将（显式或隐式）导出 api 声明为 __stdcall
@RbMm 我不知道 VB.net 期望什么
我看 - 在 vb.net 中，您可以使用任何 DllImportAttribute.CallingConvention 寻找 example。所以你可以使用任何你想要的。只需 StdCall 是默认值。但是如果你导出成员函数，你可以使用Cdecl、FastCall甚至ThisCall
@RbMm 这是否意味着如果我不使用 stdcall，VB 开发人员必须手动配置此设置才能使用我的 DLL？
是的，例如 __cdecl 需要显式声明 [DllImport("my.dll", CallingConvention=CallingConvention::Cdecl)]my_func()。如果你不使用CallingConvention - 默认为CallingConvention=CallingConvention::StdCall

【解决方案1】：

真的没有充分的理由在任何地方使用非默认调用约定/ABI（__stdcall 或其他），除非您需要调用以这种方式定义的现有接口。这只是无端的丑陋。它是在现有的 Windows 东西上完成的，它是 Win16 时代的传统货物，并且没有任何实际的理由。

【讨论】：