函数调用与名称修饰

一、函数调用的几个概念

_stdcall，_cdecl，…… 左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。
1.       _stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上“@”和参数的字节数。
2.       C调用约定（即用__cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。 _cdecl是C和C＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。
3.       __fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。 _fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上“@”前缀，在函数名后加上“@”和参数的字节数。
4.       thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。
5.       naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。 关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的Setting…/C/C++ /Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd，即__cdecl。 要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。

<script type="text/javascript"><!--google_ad_client = "pub-2019822198317345";//200x90, 创建于 07-11-21google_ad_slot = "8755139432";google_ad_width = 200;google_ad_height = 90;//--></script> <script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

二、名字修饰约定
1.       修饰名(Decoration name) “C”或者“C++”函数在内部（编译和链接）通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字符串。有些情况下使用函数的修饰名是必要的，如在模块定义文件里头指定输出“C++”重载函数、构造函数、析构函数，又如在汇编代码里调用“C””或“C++”函数等。 修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。
2.       名字修饰约定随调用约定和编译种类(C或C++)的不同而变化。函数名修饰约定随编译种类和调用约定的不同而不同，下面分别说明。
         C编译时函数名修饰约定规则：
        __stdcall调用约定：在输出函数名前加上一个下划线前缀，后面加上一个“@”符号和其参数的字节数，格式为_functionname@number。
        __cdecl调用约定仅在输出函数名前加上一个下划线前缀，格式为_functionname。
        __fastcall调用约定在输出函数名前加上一个“@”符号，后面也是一个“@”符号和其参数的字节数，格式为@functionname@number。 它们均不改变输出函数名中的字符大小写，这和PASCAL调用约定不同，PASCAL约定输出的函数名无任何修饰且全部大写。
         C++编译时函数名修饰约定规则：
        __stdcall调用约定： 1、以“?”标识函数名的开始，后跟函数名； 2、函数名后面以“@@YG”标识参数表的开始，后跟参数表； 参数表以代号表示： X–void ， D–char， E–unsigned char， F–short， H–int， I–unsigned int， J–long， K–unsigned long， M–float， N–double， _N–bool， …. PA–表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以“0”代替，一个“0”代表一次重复； 4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型，指针标识在其所指数据类型前；5、参数表后以“@Z”标识整个名字的结束，如果该函数无参数，则以“Z”标识结束。 其格式为“?functionname@@YG*****@Z”或“?functionname@@YG*XZ”，例如 int Test1（char *var1，unsigned long）—–“?Test1@@YGHPADK@Z” void Test2（） —–“?Test2@@YGXXZ”
        __cdecl调用约定： 规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的”变为“@@YA”。
        __fastcall调用约定： 规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YI”。 VC++对函数的省缺声明是“__cedcl”，将只能被C/C++调用。 CB在输出函数声明时使用4种修饰符号 //__cdecl cb的默认值，它会在输出函数名前加_，并保留此函数名不变，参数按照从右到左的顺序依次传递给栈，也可以写成_cdecl和cdecl形式。 //__fastcall 她修饰的函数的参数将尽肯呢感地使用寄存器来处理，其函数名前加@，参数按照从左到右的顺序压栈； //__pascal 它说明的函数名使用Pascal格式的命名约定。这时函数名全部大写。参数按照从左到右的顺序压栈； //__stdcall 使用标准约定的函数名。函数名不会改变。使用__stdcall修饰时。参数按照由右到左的顺序压栈，也可以是_stdcall；
三.       其他
———————————————————————
1.       调用约定：
         __cdecl 缺省是Borland C++ 的缺省的C格式命名约定，它在标识符前加一下划线，以保留它原来所有的全程标识符。参数按最右边参数优先的原则传递给栈，然后清栈。 extern “C” bool __cdecl TestFunction(); 在 def 文件中显示为 TestFunction @1 注释： @1 表示函数的顺序数，将在“使用别名”时使用。
         __pascal Pascal格式 这时函数名全部变成大写，第一个参数先压栈，然后清栈。 TESTFUNCTION @1 //def file __stdcall 标准调用 最后一个参数先压栈，然后清栈。 TestFunction @1 //def file __fastcall 把参数传递给寄存器 第一个参数先压栈，然后清栈。 @TestFunction @1 //def file
2.       解决调用约定：
         Microsoft 与 Borland 的__stdcall之间的区别是命名方式。Borland采用__stdcall 的方式去掉了名字起前的下划线。 Microsoft 则是在前加上下划线，在后加上@，再后跟为栈保留的字节数。字节数取决于参数在栈所占的空间。每一个参数都舍入为 4 的倍数加起来。这种 Miocrosoft 的 Dll 与系统的 Dll 不一样。
         参数进栈出栈方式不同。更详细的见以下，应当是很明白的了。
         ————————————————————-
When you declare a procedure or function， you can specify a calling convention using one of the directives register， pascal， cdecl， stdcall， and safecall. For example， function MyFunction(X， Y: Real): Real; cdecl; … Calling conventions determine the order in which parameters are passed to the routine. They also affect the removal of parameters from the stack， the use of registers for passing parameters， and error and exception handling. The default calling convention is register. The register and pascal conventions pass parameters from left to right; that is， the left most parameter is evaluated and passed first and the rightmost parameter is evaluated and passed last. The cdecl， stdcall， and safecall conventions pass parameters from right to left. For all conventions except cdecl， the procedure or function removes parameters from the stack upon returning. With the cdecl convention， the caller removes parameters from the stack when the call returns. The register convention uses up to three CPU registers to pass parameters， while the other conventions pass all parameters on the stack. The safecall convention implements exception “firewalls.” On Windows， this implements interprocess COM error notification. The table below summarizes calling conventions. Calling conventions Directive Parameter order Clean-up Passes parameters in registers? register Left-to-right Routine Yes pascal Left-to-right Routine No cdecl Right-to-left Caller No stdcall Right-to-left Routine No safecall Right-to-left Routine No The default register convention is the most efficient， since it usually avoids creation of a stack frame. (Access methods for published properties must use register.) The cdecl convention is useful when you call functions from shared libraries written in C or C++， while stdcall and safecall are recommended， in general， for calls to external code. On Windows， the operating system APIs are stdcall and safecall. Other operating systems generally use cdecl. (Note that stdcall is more efficient than cdecl.) The safecall convention must be used for declaring dual-interface methods. The pascal convention is maintained for backward compatibility. For more information on calling conventions， see Program control. The directives near， far， and export refer to calling conventions in 16-bit Windows programming. They have no effect in 32-bit applications and are maintained for backward compatibility only.