__cdecl相比__stdcall的优势

    呼叫X86函数的时候有两种清理堆栈的方式，在扩展的C/C++里面分别用__cdecl和__stdcall在函数声明和定义里面表示。函数的参数是用压入堆栈的方式使得函数能够通过访问堆栈访问相应的参数。比如以下函数声明：

void foo(int num);

    呼叫它的时候，计算机会使用以下汇编代码：

pushl %num

call foo

    假定是32位的X86,完成call之后ebp会指向函数的起始区域，ebp+4是函数的返回位置，也就是在函数返回时候将会回到这个地址。ebp+8就是第一个参数，ebp+12就是第二个参数，依此类推。

 

    这就有一个问题，参数会占用一定区域的内存，谁来在函数返回的时候清理它们？

    有两个办法，第一个是c语言用的标准办法，由函数的呼叫者负责清理，这就是__cdecl。第二个办法，是pascal用的标准办法，由函数的被呼叫者负责清理，这就是__stdcall。翻译为汇编语言如下：

__cdecl方式：

pushl %num

call foo

add 4,esp

    意思是把堆栈点寄存器向上移动4个字节，这样就抹去了那个参数。

    而__stdcall方式没有add 4,esp这行代码。但是在foo函数里面返回的时候有这样一句

ret 4

    意思是返回的时候将会把堆栈点寄存器向上加4。

    好了，讨论玩这两种呼叫形式的异同，现在开始讨论它们的优劣。

    __cdel相对__stdcall的第一个优势是，它很适合用于回调函数(CALLBACK)。试想一个按钮需要如下格式的回调函数

void foo(GtkWidget * button,gpointer data)

假如你只是想按下这个按钮就结束窗口们的消息循环，用__stdcall你必须老老实实写道

void __stdcall exitMainLoop(GtkWidget * button,gpointer data){

    gtk_main_quit();

}

    尽管这个函数不需要使用到button相关的信息，但是你必须老老实实把两个参数的类型写上去。这是因为函数的呼叫者不管三七二十一一律压入两个参数，然 后等着你的函数来清理堆栈，假如你写的函数签名不一致，将会损坏堆栈！比如你直接把gtk_main_quit的指针当做回调函数指针，那么由于 gtk_main_quit并不清理堆栈，就会导致8个字节（两个参数）的堆栈不可用！

    嗯，用__cdecl会怎样呢？__cdecl的呼叫者会负责清理堆栈，所以它压进多少参数，他就会清理多少个参数。那么把gtk_main_quit用做回调函数是安全的。因此我们就不必写一堆上面的代码，直接把gtk_main_quit当做回调函数即可。

    这就是__cdecl相对__stdcall的第一个优势：可以把参数列表较短而且对应参数类型相同的函数指针当做较长的函数指针使用。

    现在我们开始讨论__stdcall节省空间还是__cdecl节省空间。微软使用__stdcall来定义Win32 API，因为理论上__stdcall比较节省空间。他是这样认为的：

__stdcall消耗的空间是

ret X(X是一个地址，在32位系统为4字节)，这样就是1字节（ret）+4字节（地址)=5字节

然后__cdecl消耗的空间是

（被呼叫者）ret

（呼叫者）addl X,esp 这样就是(ret)1字节+addl esp（1字节)+X(4字节）=6字节

 

    没错，这个理论从单一个函数来看，一点也不错。但是从一个程序的角度来看，__stdcall还会因为这一字节之差胜过__cdecl？

   一个用C/C++写的程序，绝大多数函数是被动态调用的，只有一小部分程序是明文规定是在那里被调用。所谓动态调用就是函数指针交给某些系统来使用，有那 些系统来决定何时调用你的函数。这样子__stdcall的问题就来了，就是每一个自己写函数都至少带有一个ret X。假如你写千个万个__stdcall的函数，就会多千个万个ret X。相反__cdecl只会在系统的某处出现一个addl X,esp。所需写的动态调用函数越多，占得便宜越大！

   更何况，现在用C/C++写的函数也许不止有一个返回点。那么__stdcall在每一个返回点都需要有ret X，其损耗的道理和上面说的一样。

 

   这就是__cdecl的第二个优势，其实更加节省资源。