有关printf的小问题
2013-12-31 15:02
148 查看
【转载请注明出处: http://blog.csdn.net/lzl124631x】
打印结构体
曾对C++的迭代器不甚了解,于是尝试用printf直接打印迭代器,得到了诡异的输出结果。
测试系统:Win7+VS2010
当时就震惊了,一时无法理解为何有这样的输出结果。再进行尝试,发现C中也有类似的问题。
第一个printf给人一种错觉就好像s变换了它的打印值!不过自己好好想想,发现不难理解:printf中指示打印对象的指针每次只移动int的长度,因此打印三次%d只是打印了第一个s的三个成员;后两个s虽然作为参数传了进来,但是根本没有被printf打印。至于第二个printf,只是先输出了s的所有成员,然后输出了内存中排在s后面的一些无意义的数据罢了。
这里我有一个地方不明白,为何每次都是0, 0, 2147299328?即十六进制的00000000 00000000 7FFD3000?这些数据有何意义?
反观迭代器的问题也可以用同样的方法解释了:迭代器i是一个class,在内存中占据三个int的长度,对应int值分别为4539464, 0, 4539672。
但我不明白的是,这4539464, 0, 4539672有何含义?为什么第三个数总是比第二个数大208?
入栈顺序
对结果进行分析,发现输入参数是从右到左结算的,经过四次自增运算i变为4。到左数第二个i++时进行了两次自增,返回值为2;到左数第一个i++时进行了三次自增,返回值为3;而++i则是以i作为返回值的,因此最后都会返回i的值。
入栈顺序的问题让我想起了之前研究过的调用约定(Calling convention)。调用约定决定以下内容:
* 参数和返回值放置的位置(在寄存器中; 在调用栈中; 两者混合)
* 参数传递的顺序(或者单个参数不同部分的顺序)
* 调用前设置和调用后清理的工作, 在调用者和被调用者之间如何分配
* 被调用者可以直接使用哪一个寄存器有时也包括在内. (否则的话被当成ABI的细节)
* 哪一个寄存器被当作volatile的或者非volatile的, 并且如果是volatile的, 不需要被调用者恢复
1. _cdecl (C调用约定, The C default calling convention, C/C++缺省调用方式)
按从右至左的顺序压参数入栈, 由调用者把参数弹出栈. 对于"C"函数或者变量, 修饰名是在函数名前加下划线. 对于"C++"函数, 有所不同.
如函数void test(void)的修饰名是_test; 对于不属于一个类的"C++"全局函数, 修饰名是?test@@ZAXXZ.
这是MFC缺省调用约定. 由于是调用者负责把参数弹出栈, 所以可以给函数定义个数不定的参数, 如printf函数.
2. _stdcall (Pascal方式清理C方式压栈, 通常用于Win32 Api中)
按从右至左的顺序压参数入栈, 由被调用者把参数弹出栈. 对于"C"函数或者变量, 修饰名以下划线为前缀, 然后是函数名, 然后是符号"@"及参数的字节数, 如函数int func(int a, double b)的修饰名是_func@12. 对于"C++"函数, 则有所不同.
所有的Win32 API函数都遵循该约定.
3. _fastcall (快速调用约定, 通过寄存器来传送参数)
头两个DWORD类型或者占更少字节的参数被放入ECX和EDX寄存器, 其他剩下的参数按从右到左的顺序压入栈. 由被调用者把参数弹出栈, 对于"C"函数或者变量, 修饰名以"@"为前缀, 然后是函数名, 接着是符号"@"及参数的字节数, 如函数int func(int a, double b)的修饰名是@func@12. 对于"C++"函数, 有所不同.
未来的编译器可能使用不同的寄存器来存放参数.
4. thiscall (本身调用, 仅用于"C++"成员函数)
仅仅应用于"C++"成员函数. this指针存放于CX寄存器, 参数从右到左压栈. thiscall不是关键词, 因此不能被程序员指定.
5. naked call (裸调)
采用1-4的调用约定时, 如果必要的话, 进入函数时编译器会产生代码来保存ESI, EDI, EBX, EBP寄存器, 退出函数时则产生代码恢复这些寄存器的内容. naked call不产生这样的代码.
naked call不是类型修饰符, 故必须和_declspec共同使用, 如下:
__declspec(naked) int func(formal_parameters)
{
// Function body
}
打印结构体
曾对C++的迭代器不甚了解,于是尝试用printf直接打印迭代器,得到了诡异的输出结果。
测试系统:Win7+VS2010
// CPP #include <stdio.h> #include <vector> #include <iostream> using namespace std; int main(){ vector<int> t; t.push_back(1); t.push_back(2); t.push_back(3); vector<int>::iterator i = t.begin(); printf("*i=%d, i=%d, *i=%d, i=%d, *i=%d, i=%d, *i=%d\n", *i, i, *i, i, *i, i, *i); return 0; } // Output: // *i=1, i=4539464, *i=0, i=4539672, *i=1, i=4539464, *i=0
当时就震惊了,一时无法理解为何有这样的输出结果。再进行尝试,发现C中也有类似的问题。
// C #include <stdio.h> struct S{ int a; int b; int c; }; int main(){ struct S s; s.a=0; s.b=1; s.c=2; printf("%d, %d, %d\n", s, s, s); printf("%d, %d, %d, %d, %d, %d\n", s); return 0; } // Output: // 0, 1, 2 // 0, 1, 2, 0, 0, 2147299328
第一个printf给人一种错觉就好像s变换了它的打印值!不过自己好好想想,发现不难理解:printf中指示打印对象的指针每次只移动int的长度,因此打印三次%d只是打印了第一个s的三个成员;后两个s虽然作为参数传了进来,但是根本没有被printf打印。至于第二个printf,只是先输出了s的所有成员,然后输出了内存中排在s后面的一些无意义的数据罢了。
这里我有一个地方不明白,为何每次都是0, 0, 2147299328?即十六进制的00000000 00000000 7FFD3000?这些数据有何意义?
反观迭代器的问题也可以用同样的方法解释了:迭代器i是一个class,在内存中占据三个int的长度,对应int值分别为4539464, 0, 4539672。
但我不明白的是,这4539464, 0, 4539672有何含义?为什么第三个数总是比第二个数大208?
// C int main(){ int a = 1, b = 2; printf("%f %d\n", a, b); return 0; } // Output: // 0.000000 0上面这段代码也是一个问题,读取%f会读取8个字节,将输入参数a和b都读完了,而整数值1和2组成的8个字节翻译为double是0;第二个0仅是内存中无意义的数据。
入栈顺序
// C #include <stdio.h> int main(){ int i = 0; printf("%d, %d, %d, %d, %d, %d\n", i, i++, i++, ++i, ++i, i); return 0; } // Output: // 4, 3, 2, 4, 4, 4
对结果进行分析,发现输入参数是从右到左结算的,经过四次自增运算i变为4。到左数第二个i++时进行了两次自增,返回值为2;到左数第一个i++时进行了三次自增,返回值为3;而++i则是以i作为返回值的,因此最后都会返回i的值。
入栈顺序的问题让我想起了之前研究过的调用约定(Calling convention)。调用约定决定以下内容:
* 参数和返回值放置的位置(在寄存器中; 在调用栈中; 两者混合)
* 参数传递的顺序(或者单个参数不同部分的顺序)
* 调用前设置和调用后清理的工作, 在调用者和被调用者之间如何分配
* 被调用者可以直接使用哪一个寄存器有时也包括在内. (否则的话被当成ABI的细节)
* 哪一个寄存器被当作volatile的或者非volatile的, 并且如果是volatile的, 不需要被调用者恢复
1. _cdecl (C调用约定, The C default calling convention, C/C++缺省调用方式)
按从右至左的顺序压参数入栈, 由调用者把参数弹出栈. 对于"C"函数或者变量, 修饰名是在函数名前加下划线. 对于"C++"函数, 有所不同.
如函数void test(void)的修饰名是_test; 对于不属于一个类的"C++"全局函数, 修饰名是?test@@ZAXXZ.
这是MFC缺省调用约定. 由于是调用者负责把参数弹出栈, 所以可以给函数定义个数不定的参数, 如printf函数.
2. _stdcall (Pascal方式清理C方式压栈, 通常用于Win32 Api中)
按从右至左的顺序压参数入栈, 由被调用者把参数弹出栈. 对于"C"函数或者变量, 修饰名以下划线为前缀, 然后是函数名, 然后是符号"@"及参数的字节数, 如函数int func(int a, double b)的修饰名是_func@12. 对于"C++"函数, 则有所不同.
所有的Win32 API函数都遵循该约定.
3. _fastcall (快速调用约定, 通过寄存器来传送参数)
头两个DWORD类型或者占更少字节的参数被放入ECX和EDX寄存器, 其他剩下的参数按从右到左的顺序压入栈. 由被调用者把参数弹出栈, 对于"C"函数或者变量, 修饰名以"@"为前缀, 然后是函数名, 接着是符号"@"及参数的字节数, 如函数int func(int a, double b)的修饰名是@func@12. 对于"C++"函数, 有所不同.
未来的编译器可能使用不同的寄存器来存放参数.
4. thiscall (本身调用, 仅用于"C++"成员函数)
仅仅应用于"C++"成员函数. this指针存放于CX寄存器, 参数从右到左压栈. thiscall不是关键词, 因此不能被程序员指定.
5. naked call (裸调)
采用1-4的调用约定时, 如果必要的话, 进入函数时编译器会产生代码来保存ESI, EDI, EBX, EBP寄存器, 退出函数时则产生代码恢复这些寄存器的内容. naked call不产生这样的代码.
naked call不是类型修饰符, 故必须和_declspec共同使用, 如下:
__declspec(naked) int func(formal_parameters)
{
// Function body
}
相关文章推荐
- 有关有scanf及printf的一些误区及问题
- keil中printf的有关问题
- 有关printf输出的问题
- 【疑问】有关C语言中printf函数的输出和格式的问题
- [unix c]关于FOLK和PRINTF()的一个小问题
- 有关安卓java版本不对问题的解决方法
- 关于SpringBoot bean无法注入的问题(与文件包位置有关)改变自动扫描的包
- SAP客户端问题,与MSN有关
- 关于SpringBoot bean无法注入的问题(与文件包位置有关)改变自动扫描的包
- 【OpenCV】有关内存释放的一些问题
- 有关c#.net“无法加载 CSOpenGLC.dll:找不到指定的模块”的问题解决办法
- 【Android入门 三】创建项目时,有关appcompat_v7工程报错问题的分析和排除
- 在可执行jar 包中动态载入第三方jar class的有关问题
- 关于一个与CString有关的RELEASE和DEBUG不同的问题
- 有关旅行商问题(TSP)的一些网站收集
- 有关挂在ubifs卷过程中问题
- Android中有关布局的几个问题
- 主从数据库复制中有关bin-log格式问题
- c++之路进阶——斜率优化形如DP[i]=f[j]+x[i](f[j]只与j变量有关)的问题(Print Article)
- 一类有关序列的技巧问题