C++博客-C++ Coder-随笔分类-C/C++

stdcall,cdecl区别简介(转)

jackdong — Wed, 14 Nov 2012 03:03:00 GMT

stdcall,cdecl区别简介

__stdcall,__cdecl,_cdecl,_stdcall,。__fastcall,_fastcall 区别简介

1.

今天写线程函数时，发现msdn中对ThreadProc的定义有要求：DWORD WINAPI ThreadProc(LPVOID lpParameter);

不解为什么要用WINAPI宏定义，查了后发现下面的定义。于是乎需要区别__stdcall和__cdecl两者的区别； #define CALLBACK __stdcall
#define WINAPI __stdcall
#define WINAPIV __cdecl
#define APIENTRY WINAPI
#define APIPRIVATE __stdcall
#define PASCAL __stdcall
#define cdecl _cdecl
#ifndef CDECL
#define CDECL _cdecl
#endif

几乎我们写的每一个WINDOWS API函数都是__stdcall类型的，首先，需要了解两者之间的区别： WINDOWS的函数调用时需要用到栈（STACK，一种先入后出的存储结构）。当函数调用完成后，栈需要清楚，这里就是问题的关键，如何清除？？如果我们的函数使用了_cdecl，那么栈的清除工作是由调用者，用COM的术语来讲就是客户来完成的。这样带来了一个棘手的问题，不同的编译器产生栈的方式不尽相同，那么调用者能否正常的完成清除工作呢？答案是不能。如果使用__stdcall，上面的问题就解决了，函数自己解决清除工作。所以，在跨（开发）平台的调用中，我们都使用__stdcall（虽然有时是以 WINAPI的样子出现）。那么为什么还需要_cdecl呢？当我们遇到这样的函数如fprintf()它的参数是可变的，不定长的，被调用者事先无法知道参数的长度，事后的清除工作也无法正常的进行，因此，这种情况我们只能使用_cdecl。到这里我们有一个结论，如果你的程序中没有涉及可变参数，最好使用__stdcall关键字。

2.

__cdecl,__stdcall是声明的函数调用协议.主要是传参和弹栈方面的不同.一般c++用的是__cdecl,windows里大都用的是__stdcall(API)

__cdecl是C/C++和MFC程序默认使用的调用约定，也可以在函数声明时加上__cdecl关键字来手工指定。采用__cdecl约定时，函数参数按照从右到左的顺序入栈，并且由调用函数者把参数弹出栈以清理堆栈。因此，实现可变参数的函数只能使用该调用约定。由于每一个使用 __cdecl约定的函数都要包含清理堆栈的代码，所以产生的可执行文件大小会比较大。__cdecl可以写成_cdecl。
__stdcall调用约定用于调用Win32 API函数。采用__stdcall约定时，函数参数按照从右到左的顺序入栈，被调用的函数在返回前清理传送参数的栈，函数参数个数固定。由于函数体本身知道传进来的参数个数，因此被调用的函数可以在返回前用一条ret n指令直接清理传递参数的堆栈。__stdcall可以写成_stdcall。
__fastcall约定用于对性能要求非常高的场合。__fastcall约定将函数的从左边开始的两个大小不大于4个字节（DWORD）的参数分别放在ECX和EDX寄存器，其余的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的堆栈。__fastcall可以写成 _fastcall

3.

__stdcall:

_stdcall 调用约定相当于16位动态库中经常使用的PASCAL调用约定。

在32位的VC++5.0中PASCAL调用约定不再被支持（实际上它已被定义为__stdcall。除了__pascal 外，__fortran和__syscall也不被支持），取而代之的是__stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。

_stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。

_cdecl:

_cdecl c调用约定, 按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。

_cdecl是C和C＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。

__fastcall:

__fastcall调用约定是"人"如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。

_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。

thiscall:

thiscall仅仅应用于"C++"成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。

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。

名字修饰约定

1、修饰名(Decoration name)
“C”或者“C++”函数在内部（编译和链接）通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字符串。有些情况下使用函数的修饰名是必要的，如在模块定义文件里头指定输出“C++”重载函数、构造函数、析构函数，又如在汇编代码里调用“C””或“C++”函数等。

修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。

2、名字修饰约定随调用约定和编译种类(C或C++)的不同而变化。函数名修饰约定随编译种类和调用约定的不同而不同，下面分别说明。

a、C编译时函数名修饰约定规则：

__stdcall调用约定在输出函数名前加上一个下划线前缀，后面加上一个“@”符号和其参数的字节数，格式为_functionname@number。

__cdecl调用约定仅在输出函数名前加上一个下划线前缀，格式为_functionname。

__fastcall调用约定在输出函数名前加上一个“@”符号，后面也是一个“@”符号和其参数的字节数，格式为@functionname@number。

它们均不改变输出函数名中的字符大小写，这和PASCAL调用约定不同，PASCAL约定输出的函数名无任何修饰且全部大写。

b、C++编译时函数名修饰约定规则：

__stdcall调用约定：
1、以“?”标识函数名的开始，后跟函数名；
2、函数名后面以“@@YG”标识参数表的开始，后跟参数表；
3、参数表以代号表示：
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调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YA”。

__fastcall调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YI”。
VC++对函数的省缺声明是“__cedcl“,将只能被C/C++调用.

CB在输出函数声明时使用4种修饰符号
//__cdecl
cb的默认值，它会在输出函数名前加_，并保留此函数名不变，参数按照从右到左的顺序依次传递给栈，也可以写成_cdecl和cdecl形式。
//__fastcall
她修饰的函数的参数将尽肯呢感地使用寄存器来处理，其函数名前加@，参数按照从左到右的顺序压栈；
//__pascal
它说明的函数名使用Pascal格式的命名约定。这时函数名全部大写。参数按照从左到右的顺序压栈；
//__stdcall
使用标准约定的函数名。函数名不会改变。使用__stdcall修饰时。参数按照由右到左的顺序压栈，也可以是_stdcall；

VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用.

注意：

1、_beginthread需要__cdecl的线程函数地址，_beginthreadex和CreateThread需要__stdcall的线程函数地址。

2、一般WIN32的函数都是__stdcall。而且在Windef.h中有如下的定义：

#define CALLBACK __stdcall

#define WINAPI　 __stdcall

3、extern "C" _declspec(dllexport) int __cdecl Add(int a, int b);

   typedef int (__cdecl*FunPointer)(int a, int b);

   修饰符的书写顺序如上。

4、extern "C"的作用：如果Add(int a, int b)是在c语言编译器编译，而在c++文件使用，则需要在c++文件中声明：extern "C" Add(int a, int b)，因为c编译器和c++编译器对函数名的解释不一样（c++编译器解释函数名的时候要考虑函数参数，这样是了方便函数重载，而在c语言中不存在函数重载的问题），使用extern "C"，实质就是告诉c++编译器，该函数是c库里面的函数。如果不使用extern "C"则会出现链接错误。

一般象如下使用：

#ifdef _cplusplus

#define EXTERN_C extern "C"

#else

#define EXTERN_C extern

#endif

#ifdef _cplusplus

extern "C"{

#endif

EXTERN_C int func(int a, int b);

#ifdef _cplusplus

}

#endif

5、MFC提供了一些宏，可以使用AFX_EXT_CLASS来代替__declspec(DLLexport)，并修饰类名，从而导出类，AFX_API_EXPORT来修饰函数，AFX_DATA_EXPORT来修饰变量

AFX_CLASS_IMPORT：__declspec(DLLexport)

AFX_API_IMPORT：__declspec(DLLexport)

AFX_DATA_IMPORT：__declspec(DLLexport)

AFX_CLASS_EXPORT：__declspec(DLLexport)

AFX_API_EXPORT：__declspec(DLLexport)

AFX_DATA_EXPORT：__declspec(DLLexport)

AFX_EXT_CLASS：#ifdef _AFXEXT

   AFX_CLASS_EXPORT

        #else

   AFX_CLASS_IMPORT

6、DLLMain负责初始化(Initialization)和结束(Termination)工作，每当一个新的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调用DLLMain。但是，使用TerminateProcess或 TerminateThread结束进程或者线程，不会调用DLLMain。

7、一个DLL在内存中只有一个实例

DLL程序和调用其输出函数的程序的关系：

1)、DLL与进程、线程之间的关系

DLL模块被映射到调用它的进程的虚拟地址空间。

DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。

DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。

DLLDLL可以有自己的数据段，但没有自己的堆栈，使用调用进程的栈，与调用它的应用程序相同的堆栈模式。

2)、关于共享数据段

DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储 (TLS，Thread Local Strorage)。

http://blog.sina.com.cn/s/blog_494e45fe0100l4wv.html

jackdong 2012-11-14 11:03 发表评论

Visual Studio 2010控制台程序无法输出中文

jackdong — Sat, 03 Nov 2012 03:09:00 GMT

Visual Studio 2008控制台程序无法输出中文！？解决方法只需要设置一下区域即可。没有设置区域前如下图：

包含头文件：#include

函数：_tsetlocale(LC_ALL, _T("chs"));

设置区域后如下图：

参考，摘自微软MSDN

控制台中的编码程序员在对控制台或“文本模式”应用程序编程时可同时使用 Unicode 和 SBCS 或 DBCS 编码。出于承袭方面的考虑，非 Unicode 控制台 I/O 函数使用控制台代码页（默认为 OEM 代码页）。Windows 中的所有其他非 Unicode 函数都使用 Windows 代码页。这意味着其他函数可能无法正确地处理由控制台函数返回的字符串，反之亦然。例如，如果 FindFirstFileA 返回了一个包含某个非 ASCII 字符的字符串，WriteConsoleA 将无法正常地显示该字符串。

要一直跟踪哪些函数需要哪些编码并正确转换文本参数的编码非常困难。函数 SetFileApisToOEM、SetFileApisToANSI 和帮助程序函数 AreFileApisANSI 的引入极大地简化了此项工作。前两个函数可接受或返回文件名称，对 KERNEL32.dll 导出的非 Unicode 函数有效果。顾名思义，SetFileApisToOEM 将这些函数设置为接受或返回与当前系统区域设置对应的 OEM 字符集中的文件名称，而 SetFileApisToANSI 用于为这些名称恢复默认值（Windows ANSI 编码）。使用 AreFileApisANSI 可查询到当前选定的编码。

利用 SetFileApisToOEM 可轻松地解决 WindFirstFileA（或 GetCurrentDirectoryA，或 Win32 API 的任何文件处理函数）的结果无法直接传送给 WriteConsoleA 这一问题：在调用 SetFileApisToOEM 后，WindFirstFileA 将返回以 OEM（而不是以 Windows ANSI 字符集）编码的文本。但此解决方案并非应对所有 Windows ANSI 与 OEM 不兼容情况的万能良方。设想您需要从某个文件处理函数中获取文本，然后将其输出到控制台，接着用其他函数（不受SetFileApisToOEM 的影响）处理该文本。这种绝对理想的情况需要更改编码。否则，您将需要调用 SetFileApisToOEM 以获取用于控制台输出的数据，然后调用SetFileApisToANSI 得到同一文本（使用另一种编码）进行内部处理。另一种 SetFileApisToOEM 无法发挥作用的情况对命令行参数的处理：当您的应用程序的入口点为 main（而不是 wmain）时，参数始终作为 Windows ANSI 字符串数组进行传递。这一切显然使编写非 Unicode 控制台应用程序的程序员的工作变得更复杂了。

更为复杂的是为控制台编写的 8 位代码需要处理两种不同类型的区域设置。在编写代码时，您可以使用 Win32 API 或 C 运行时库函数。Win32 API 的 ANSI 函数假定文本是针对当前控制台代码页（系统区域设置默认定义的）编码的。SetConsoleCP 和 SetConsoleOutputCP 函数可更改这些操作中使用的代码页。用户可在命令提示符下调用 chcp or mode con cp select= 命令，这将会更改当前控制台的代码页。设置固定的控制台代码页的另一种方法是用默认的代码页集创建控制台快捷方式（仅适用于东亚本地化版本的操作系统）。应用程序应能够响应用户的操作。

C 运行时库（CRT 函数）中区分区域设置函数可依照 (_w)setlocale 调用所定义的设置处理文本。如果代码中未调用 (_w)setlocale，则 CRT 函数对这些操作使用 ANSI "C" 语言不变区域设置，这样就丢失了特定于语言的功能。

该函数的声明为：

setlocale( int category, const char *locale)或

_wsetlocale( int category, const wchar_t *locale)其中 "category" 用于定义受影响的特定于区域的设置（如果指定了 LC_ALL，则全部定义）。可变区域设置可以是显式区域设置名称或下面的某一项：

".OCP" 指与当前用户区域设置对应的 OEM 代码页
".ACP" 或 "" 指与当前用户区域设置对应的 Windows 代码页
".OCP" 和 ".ACP" 参数始终引用用户区域设置（而不是系统区域设置）的设置值。因此不能将它们用于设置 LC_CTYPE。此 "category" 定义了 Unicode 向 8 位转换的规则和其他文本处理程序，必须遵循控制台的设置（可使用 GetConsoleCP 和 GetConsoleOutputCP 访问）。

对控制台应用程序最佳的长期解决方案是使用 Unicode，因为 Unicode 接口是针对 Win32 API 和 C 运行时库定义的。今后的编程模型仍需要您显式地设置区域设置，但至少可肯定通过 Win32 和 CRT 看到的文本不再需要进行代码转换。

jackdong 2012-11-03 11:09 发表评论

C/C++中如何精确计时

jackdong — Sun, 21 Oct 2012 04:45:00 GMT

http://blog.csdn.net/bendanban/article/details/7673607
给程序计时对于程序员来说实在是太重要了，在windows上的那个clock（）实在是不够精确，精度只有10ms，真让人难过。研究了下windows下使用C、C++计时的函数，给大家分享下。

主要就是两个函数的使用。我先把一段可以运行的代码贴出来，然后讲讲这两个函数。

#include <windows.h>
#include <stdio.h>
int main(int argc, char **argv)
{
    LARGE_INTEGER freq;
    LARGE_INTEGER start_t, stop_t;
    double exe_time;
    QueryPerformanceFrequency(&freq);
    fprintf(stdout, "The frequency of your pc is %d.\n", freq.QuadPart);
    QueryPerformanceCounter(&start_t);
    Sleep(1000);
    QueryPerformanceCounter(&stop_t);
    exe_time = 1e3*(stop_t.QuadPart-start_t.QuadPart)/freq.QuadPart;
    fprintf(stdout, "Your program executed time is %fms.\n", exe_time);
    getchar();
    return 0;
}

1、LARGE_INTEGER在微软的编译器中实际上是一个union，它的定义如下：

typedef union _LARGE_INTEGER
{
    struct
    {
        DWORD LowPart;
        LONG HighPart;
    };
    struct
    {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER,  *PLARGE_INTEGER;

如果你使用的编译器支持64位整数，那么可以使用QuadPart来引用变量的值。如果你的编译器不支持64位整数，那么可以使用LowPart和HighPart来引用64位整数的低32位和高32位。

2、QueryPerformanceFrequncy(LARGE_INTEGER *freq)

它用于获得你的机器一秒钟执行多少次，就是你的时钟周期。

3、QueryPerformanceCounter(LARGE_INTEGER *lpPerformanceCount)

它获得的是CPU从开机以来执行的时钟周期数。

O啦。。。。好好用用它吧。

jackdong 2012-10-21 12:45 发表评论

使用编译器来使用宏变量

jackdong — Sun, 21 Oct 2012 04:41:00 GMT

http://blog.csdn.net/bendanban/article/details/7753995
刚学了一招，可以使用编译器的-D选项来定义程序中使用的宏。

#include <stdio.h>
int main(int argc, char **argv)
{
    #ifdef MY_MAC
    printf("Hello -D.\n");
    #else
    printf("MY_MAC was not defined.\n");
    #endif
    return 0;
}

上面的代码中使用了MY_MAC宏，

【】$g++ -DMY_MAC -o dtest dtest.c

执行结果：

【】$ ./dtest
Hello -D.
【】$

无掉-D选项，重新编译，执行结果：

【】$ g++ ./dtest.c -o dtest
【】$ ./dtest
MY_MAC was not defined.

我们可以利用编译器这个选项来调试我们的程序奥。

如果我的宏代表一个常量怎么办呢？？

看看修改后的代码：

#include <stdio.h>
int main(int argc, char **argv)
{
    #ifdef MY_MAC
    printf("Hello -D. %d\n", MY_MAC);
    #else
    printf("MY_MAC was not defined.\n");
    #endif
    return 0;
}

我输出了宏代表的值。

在终端执行一下命令：

【】$ g++ -DMY_MAC=5 ./dtest.c -o dtest
【】$ ./dtest
Hello -D. 5
【】$

如果程序中有多个宏可以这样编译

【】$g++ -DMAC1=5 -DMAC2=6 soucefile.c

^_^，，很兴奋是吧？？这样我们就不用在代码里修改宏变量了。。

jackdong 2012-10-21 12:41 发表评论

C++为什么不建议使用malloc,calloc,realloc来分配内存?

jackdong — Fri, 19 Oct 2012 14:57:00 GMT

http://blog.csdn.net/eclipser1987/article/details/8024555

为什么C++中不建议使用malloc calloc realloc等C语言函数?因为:这样分配的空间,返回的指针需要通过free来释放,但free释放空间不同于delete,free不会执行析构函数!

/*
* File:   main.cpp
* Author: Vicky.H
* Email:  eclipser@163.com
*/
#include <iostream>
#include <cstdlib>
#include <memory>

class A {
public:

    A() {
        std::cout << "create A" << std::endl;
    }

    A(const A& o) {
        std::cout << "copy A" << std::endl;
    }

    ~A() {
        std::cout << "delete A" << std::endl;
    }
};

/*
*
*/
int main(void) {

    char* buf1 = (char*) malloc(10); //
    char* buf2 = (char*) calloc(1, 10); // 效果虽然与上面一样,不同的是,calloc会将空间初始化为0.

    free(buf1);
    free(buf2);

    std::cout << "---------------------------" << std::endl;

    // 为什么C++中不建议使用malloc calloc realloc等C语言函数?因为:这样分配的空间,返回的指针需要通过free来释放,但free释放空间不同于delete,free不会执行析构函数!

    A* ap = (A*) malloc(sizeof (class A) * 10);
    std::uninitialized_fill_n(ap, 10, A());
    free(ap); // 调用1次create A ,1次delete A 10次copy A
    return 0;
}

---------------------------
create A
copy A
copy A
copy A
copy A
copy A
copy A
copy A
copy A
copy A
copy A
delete A

虽然实例程序,对空间的分配释放没有任何错误,但在某些情况,比如A类的析构伴随着某些特殊处理,将导致程序异常!

jackdong 2012-10-19 22:57 发表评论