C++ __cdecl 或 __stdcall 在 Windows 上？

__cdecl or __stdcall on Windows?

提问by Etienne Dechamps

I'm currently developing a C++ library for Windows which will be distributed as a DLL. My goal is to maximize binary interoperability; more precisely, the functions in my DLL must be usable from code compiled with multiple versions of MSVC++ and MinGW without having to recompile the DLL. However, I'm confused about which calling convention is best, cdeclor stdcall.

我目前正在为 Windows 开发一个 C++ 库，它将作为 DLL 分发。我的目标是最大化二进制互操作性；更准确地说，我的 DLL 中的函数必须可以从使用多个版本的 MSVC++ 和 MinGW 编译的代码中使用，而无需重新编译 DLL。但是，我对哪种调用约定最好cdecl或stdcall.

Sometimes I hear statements like "the C calling convention is the only one guaranteed to be the same accross compilers", which contrasts with statements like "There are some variations in the interpretation of cdecl, particularly in how to return values". This doesn't seem to stop certain library developers (like libsndfile) to use the C calling convention in the DLLs they distribute, without any visible problems.

有时我会听到诸如“C 调用约定是唯一一个保证与跨编译器相同的声明”之类的语句，这与“的解释存在一些变化cdecl，特别是如何返回值” 之类的语句形成对比。这似乎并没有阻止某些库开发人员（如libsndfile）在他们分发的 DLL 中使用 C 调用约定，而没有任何可见的问题。

On the other hand, the stdcallcalling convention seems to be well-defined. From what I've been told, all Windows compilers are basically required to follow it because it's the convention used for Win32 and COM. This is based on the assumption that a Windows compiler without Win32/COM support would not be very useful. A lot of code snippets posted on forums declare functions as stdcallbut I can't seem to find one single post which clearly explains why.

另一方面，stdcall调用约定似乎是明确定义的。据我所知，所有 Windows 编译器基本上都必须遵循它，因为它是用于 Win32 和 COM 的约定。这是基于这样一个假设，即没有 Win32/COM 支持的 Windows 编译器不会非常有用。论坛上发布的许多代码片段都将函数声明为，stdcall但我似乎找不到一篇明确解释原因的帖子。

There's too much conflicting information out there, and every search I run gives me different answers which doesn't really help me decide between the two. I'm searching for a clear, detailed, argumented explanation as to why I should choose one over the other (or why the two are equivalent).

那里有太多相互矛盾的信息，我运行的每次搜索都会给我不同的答案，这并不能真正帮助我在两者之间做出决定。我正在寻找一个清晰、详细、有争议的解释，说明为什么我应该选择一个而不是另一个（或者为什么这两个是等价的）。

Note that this question not only applies to "classic" functions, but also to virtual member function calls, since most client code will interface with my DLL through "interfaces", pure virtual classes (following patterns described e.g. hereand there).

请注意，此问题不仅适用于“经典”函数，还适用于虚拟成员函数调用，因为大多数客户端代码将通过“接口”、纯虚拟类（例如此处和那里描述的以下模式）与我的 DLL 进行交互。

采纳答案by Etienne Dechamps

I just did some real-world testing (compiling DLLs and applications with MSVC++ and MinGW, then mixing them). As it appears, I had better results with the cdeclcalling convention.

我只是做了一些实际测试（使用 MSVC++ 和 MinGW 编译 DLL 和应用程序，然后将它们混合）。看起来，我使用cdecl调用约定获得了更好的结果。

More specifically: the problem with stdcallis that MSVC++ mangles names in the DLL export table, even when using extern "C". For example foobecomes _foo@4. This only happens when using __declspec(dllexport), not when using a DEF file; however, DEF files are a maintenance hassle in my opinion, and I don't want to use them.

更具体地说：问题stdcall在于 MSVC++ 会破坏 DLL 导出表中的名称，即使使用extern "C". 例如foo变成_foo@4. 这仅在使用__declspec(dllexport)时发生，而不是在使用 DEF 文件时发生；但是，在我看来，DEF 文件维护起来很麻烦，我不想使用它们。

The MSVC++ name mangling poses two problems:

MSVC++ 名称修改带来了两个问题：

• Using GetProcAddresson the DLL becomes slightly more complicated;
• MinGW by default doesn't prepend an undescore to the decorated names (e.g. MinGW will use foo@4instead of _foo@4), which complicates linking. Also, it introduces the risk of seeing "non-underscore versions" of DLLs and applications pop up in the wild which are incompatible with the "underscore versions".

• GetProcAddress在 DLL 上使用变得稍微复杂一些；
• 默认情况下，MinGW 不会在修饰的名称前添加 undescore（例如 MinGW 将使用foo@4代替_foo@4），这会使链接复杂化。此外，它还引入了看到 DLL 和应用程序的“非下划线版本”的风险，这些应用程序与“下划线版本”不兼容。

I've tried the cdeclconvention: interoperability between MSVC++ and MinGW works perfectly, out-of-the-box, and names stay undecorated in the DLL export table. It even works for virtual methods.

我已经尝试过cdecl约定：MSVC++ 和 MinGW 之间的互操作性完美运行，开箱即用，并且名称在 DLL 导出表中保持未修饰。它甚至适用于虚拟方法。

For these reasons, cdeclis a clear winner for me.

由于这些原因，cdecl对我来说是一个明显的赢家。

回答by Brandon Moretz

The biggest difference in the two calling conventions is that "__cdecl" places the burden of balancing the stack after a function call on the caller, which allows for functions with variable amounts of arguments. The "__stdcall" convention is "simpler" in nature, however less flexible in this regard.

两种调用约定的最大区别在于，“ __cdecl”在函数调用之后将平衡堆栈的负担放在调用者身上，这允许函数具有可变数量的参数。“__stdcall”约定本质上“更简单”，但在这方面不太灵活。

Also, I believe managed languages use stdcall convention by default, so anyone using P/Invoke on it would have to explicitly state the calling convention if you go with cdecl.

此外，我相信托管语言默认使用 stdcall 约定，因此如果您使用 cdecl，任何在其上使用 P/Invoke 的人都必须明确说明调用约定。

So, if all of your function signatures are going to be statically defined I would probably lean toward stdcall, if not cdecl.

所以，如果你所有的函数签名都是静态定义的，我可能会倾向于 stdcall，如果不是 cdecl。

回答by user2471214

In terms of security, the __cdeclconvention is "safer" because it is the caller that needs to deallocate the stack. What may happen in a __stdcalllibrary is that the developer might have forgotten to deallocate the stack properly, or an attacker might inject some code by corrupting the DLL's stack (e.g. by API hooking) which is then not checked by the caller. I don't have any CVS security examples that show my intuition is correct.

在安全性方面，__cdecl约定是“更安全的”，因为需要释放堆栈的是调用者。在__stdcall库中可能发生的情况是开发人员可能忘记正确释放堆栈，或者攻击者可能通过破坏 DLL 的堆栈（例如通过 API 挂钩）来注入一些代码，然后调用者不会检查这些代码。我没有任何 CVS 安全示例表明我的直觉是正确的。