__stdcall由被调用函数清理栈且不支持可变参数,__cdecl由调用方清理栈并支持可变参数;Windows API和回调函数必须用__stdcall,C标准库函数默认用__cdecl,约定不匹配会导致栈失衡、崩溃或链接失败。
它们是 Windows 平台上控制函数调用约定(calling convention)的关键字,直接影响栈清理责任归属和参数压栈顺序。你不是“想用才用”,而是**调用 Windows API 或写 DLL 导出函数时,几乎必然要匹配目标要求**——比如 WinMain 必须是 __stdcall,而普通 C++ 成员函数默认是 __thiscall,混用会导致栈失衡、崩溃或神秘的返回值错误。
绝大多数自由函数(如 printf、malloc)和你自己写的普通全局函数,默认就是 __cdecl:调用者负责清理栈,支持可变参数(...)。但 Windows 系统 DLL(如 user32.dll、kernel32.dll)导出的函数几乎全是 __stdcall。如果你直接声明:
typedef int (*FuncPtr)(int, char*); // 错!没指定调用约定
然后去 GetProcAddress 拿到函数指针并调用,大概率 crash——因为编译器按 __cdecl 生成调用代码,而实际函数期望自己清理栈。
typedef int (__stdcall *FuncPtr)(int, char*);
WNDPROC)也必须用 __stdcall,否则窗口过程一执行就崩main 函数不能加 __cdecl(它本来就是),但加了也不报错;加 __stdcall 会链接失败(LNK2019)__stdcall 要求被调函数自己清理栈,参数从右向左压栈(这点和 __cdecl 相同),但**不支持可变参数**——所以你不能写 int __stdcall foo(int a, ...),编译直接报错 C2729。
立即学习“C++免费学习笔记(深入)”;
__stdcall 会自动在函数名前加下划线、后加 @N(N 是参数总字节数),例如 MyFunc@8;__cdecl 只加下划线 _MyFunc。这影响 GetProcAddress 查找extern "C" + __declspec(dllexport) 避免名字修饰__fastcall(实际是微软定义的 x64 调用约定),__stdcall 和 __cdecl 在 64 位下被忽略(仅作语法兼容)栈不平衡不会立刻报错,而是表现为:函数返回后局部变量乱码、后续函数调用参数错位、ESP 值异常、程序在无关代码处崩溃。调试时看反汇编最直接:
add esp, N(__cdecl 特征),但被调函数结尾有 ret N(__stdcall 特征),说明约定不匹配dumpbin /exports 查看 DLL 实际导出符号名,比对是否带 @ 后缀真正麻烦的是跨语言调用——比如 Python ctypes 加载 DLL,必须用 WINFUNCTYPE(对应 __stdcall)而非 CALLBACK(其实也是 __stdcall,但别被名字误导),否则照样崩。约定这事,差一个关键字,整个调用链就不可靠。