C++中的__stdcall和__cdecl有什么区别？(不同的函数调用约定)

__cdecl由调用者清理栈，__stdcall由被调者清理栈；前者符号名如_foo，后者如_foo@8；二者ABI不兼容，混用导致栈失衡崩溃。

__stdcall 和 __cdecl 的核心区别在栈清理责任方和参数压栈顺序，实际影响函数符号名、ABI 兼容性与跨语言调用。

谁负责清理栈？这是最直接的差异

调用约定本质是“调用者和被调用者之间关于栈怎么用”的协议。关键分歧点在于：函数返回后，谁来把传入的参数从栈上弹掉？

• __cdecl：调用者（caller）负责清理栈。这意味着每个调用该函数的地方，编译器都要生成 add esp, N（x86）或等效指令来回收参数空间。
• __stdcall：被调用者（callee）负责清理栈。函数自身在 ret 时带立即数，如 ret 8，一次性弹掉 8 字节参数。

这导致同一函数在不同约定下生成的汇编不同，也决定了它们不能混用 —— 否则栈会失衡，轻则局部变量错乱，重则崩溃。

函数名修饰（name mangling）规则不同

为了防止链接时符号冲突，MSVC 对带调用约定的函数名做前缀/后缀修饰。这对 C++ 模板、extern "C" 和 DLL 导出尤其关键：

• int __cdecl foo(int a, char b) → 符号名通常是 _foo（前导下划线）
• int __stdcall foo(int a, char b) → 符号名通常是 _foo@8（@ 后跟参数总字节数）

如果你用 GetProcAddress 手动加载 DLL 中的函数，写错修饰名（比如该写 "_MyFunc@12" 却写了 "MyFunc"），就会返回 NULL —— 这是 Windows 平台 DLL 调用失败的常见原因。

参数压栈顺序相同，但 ABI 兼容性不互通

两者都采用从右到左压栈（push b; push a），所以单看参数布局没区别。但 ABI（应用二进制接口）不兼容：

• 你不能用 __cdecl 声明去调用一个实际按 __stdcall 编译的函数（即使原型一致），因为调用方不会清理栈，而被调用方虽然清了，但调用方后续代码可能基于错误的栈顶位置读写。
• 反过来也不行：用 __stdcall 声明调 __cdecl 函数，会导致被调函数自己清栈（清得少），而调用方又不补清，栈指针永久偏移。

典型场景：Windows API 函数（如 CreateWindowEx）全部是 __stdcall；而 C 标准库（printf, malloc）是 __cdecl。混用声明等于主动制造未定义行为。

现代开发中哪些地方还必须关心？

纯 C++ 项目里，除非对接特定系统层，一般不用显式写。但以下情况绕不开：

• 写 DLL 并导出函数给 C 或其他语言调用时，必须显式指定约定（常选 __stdcall 以匹配 Windows API 风格）；
• 用 typedef 定义函数指针类型时，约定是类型的一部分：typedef int (__stdcall *PFN)(int); 和 int (__cdecl *PFN)(int) 是不同类型，不可赋值；
• 使用 MinGW 或 Clang 编译 Windows 程序时，__stdcall 可能默认不启用，需加 -mstdps 或确保头文件已正确定义。

最容易被忽略的是：头文件里声明了 __stdcall，但实现文件忘了加，或者 DLL 工程设置里调用约定不一致 —— 此时链接可能通过，运行时才崩，且难以定位。