Linux C下自加(a++)与左值、右值、临时变量
看到一道“经典Linux C“面试题,关于左值和右值的。
华为笔试题 1.写出判断ABCD四个表达式的是否正确, 若正确, 写出经过表达式中 a的值(3分) int a = 4; (A)a += (a++); (B) a += (++a) ;(C) (a++) += a;(D) (++a) += (a++); a = ? 答:C错误,左侧不是一个有效变量,不能赋值,可改为(++a) += a; 改后答案依次为9,10,10,11
可以看出,这个题除了测试你关于++a与a++中“自加1是先生效还是后生效?”以外,还要测试你对左值和右值的理解。
根据这个参考答案大胆的猜测一下过程:
A选项,a加上自身(a自加1还没有生效),得a的双倍,随后a的自加1生效,变成了2a+1,即9。
B选项,a加上自身的自加1结果。注意:这个自加1已经生效了,因为是赋值语句,等号右边先生效?等号右边的a变5,左边的a随即也变成了5,所以是两个a的自加1(即4 + 1 == 5)相加,结果10。。。。
C选项,a的自加1加上a的自身,这里因为(a++)是个“临时变量”,没有内存地址(即右值),所以不能用,替换成左值(++a),根据B选项等号右边先生效的原则,应该是4+4,之后再自加1,变成9才对(或者理解为4+1,再+4,反正没区别)。。。。。反正顺序不对,有冲突~!!
除非说++a在整个赋值表达式之前就生效,而a++在整个表达式结束时才生效。这样才能解释通!!!但是这样C就是错的。
D选项,a的前自加1(值为5)加上a的后自加(为便于理解,写成5++),结果10,表达式结束后另一个a++生效,结果11?
那么,事实究竟如何?
还是做个程序测试了下的好,这种比较迷惑人的东西一定要自己亲自操作一下,多试试条件,看看细小差别。
因为这四个选项是重复的,所以把a换成了abcd四种(这些自加赋值语句一定不要放在printf里,printf要单独放,因为自加导致打印结果不准确。)
#include<stdio.h> //some unique and different useage of plusplus main(){ int a = 4; int b = 4; int c = 4; int d = 4; a += (a++); b += (++b); //who said that ++c could be work in linux C???? // (c++) += c; // (++c) += c; // (++d) += d++; printf("a = %d\n",a); printf("b = %d\n",b); printf("c = %d\n",c); printf("d = %d\n",d); } gcc编译结果: aplusplus.c:12:8: error: lvalue required as left operand of assignment aplusplus.c:13:8: error: lvalue required as left operand of assignment aplusplus.c:14:8: error: lvalue required as left operand of assignment 这三行分别指注释掉的三个语句~~实测发现,(c++)不能当做左值,(++c)和(++d)同样不行,和括号也没有关系,那么在我的
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
貌似测试不了++a作为左值的情况了。
这块弄不了,先挂起,看看左值右值的问题吧,根据描述,右值一般是没有内存地址的,是临时的,通俗点说,是个表达式,不是个值。看看我们的执行过程。
用gdb设断点,看过程:
首先,a(值为0x4)和b(值为0x4)分别压入栈,地址分别是0x10和0x14
4 int a = 4; 1: x/i $pc => 0x80483ed <main+9>: movl $0x4,0x10(%esp) (gdb) si 5 int b = 4; 1: x/i $pc => 0x80483f5 <main+17>: movl $0x4,0x14(%esp)
Breakpoint 1, main () at aplusplus.c:9 9 a += (a++); 1: x/i $pc => 0x804840d <main+41>: mov 0x10(%esp),%eax第九行是a += (a++);处相应断点,看下a和b的自加过程。
=> 0x804840d <main+41>: mov 0x10(%esp),%eax 0x8048411 <main+45>: add %eax,%eax 0x8048413 <main+47>: mov %eax,0x10(%esp) 0x8048417 <main+51>: addl $0x1,0x10(%esp) 0x804841c <main+56>: addl $0x1,0x14(%esp) 0x8048421 <main+61>: mov 0x14(%esp),%eax 0x8048425 <main+65>: add %eax,%eax 0x8048427 <main+67>: mov %eax,0x14(%esp) 。。。。。。先看a += a++;
a从栈地址0x10中移入eax寄存器中,
在eax寄存器中自加(相当于double了一下4*2 == 8),
从eax再移回栈地址0x10,
最后,给栈地址0x10中加入直接数1(8+1 == 9)
然后b += ++b;
先把直接数1加到b所在栈地址0x14中(4+1 == 5),
然后从栈中移动b(5)到eax寄存器中,
在eax寄存器中自加(5*2 == 10),
移动b回栈中地址0x14。
结论:不管逻辑上怎么认为,什么“++a为自加1先生效,a++为自加1后生效,临时变量不可被赋值,等号左边右边谁先生效”。到最后,怎么实现都是编译器说了算,以下结果至少能代表我这个版本的 gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 下正确。
a++和++b,中间过程类似,都是在eax寄存器中,用自己加自己(即乘以2),主要区别就是自加1的位置,一个在最前,一个在最后。不知道其他版本的编译器,至少我这个版本的编译器把问题简化了,根本不允许在赋值符号”=“左边放++a或a++一类语句,也就是说++a也不被认为是左值,所以根本没法区分赋值符号”=“左右的先后一说。
那么,还有临时变量一说么?再看两种情况:test++和d += a++(因为之前a和b都是和自己相加,这两个情况没测到)
8 int test = 5; 1: x/i $pc => 0x804840d <main+41>: movl $0x5,0x2c(%esp) (gdb) 9 test++; 1: x/i $pc => 0x8048415 <main+49>: addl $0x1,0x2c(%esp)直接把立即数加到test所占的栈空间0x2c中
22 d += a++; 1: x/i $pc => 0x804848c <main+168>: mov 0x1c(%esp),%eax 把a移到eax寄存器中, => 0x8048490 <main+172>: add %eax,0x28(%esp) a的值直接加到d所在内存地址中(d += a) => 0x8048494 <main+176>: addl $0x1,0x1c(%esp) 将立即数1加给a
所谓临时变量不临时变量,至少从这个角度无法证明,尤其单独的test++,直接在原地址修改,当然有地址,当然是左值(不足之处是现在的这个是宏汇编,还不是单独的汇编命令,不够详细)。只有在a += a++;之类更复杂的语句中才能体会这种差别来,所以,这应该是编程语言和编译器之间协调的一个过程吧,编译器看要怎么来解决某种情况,怎么实现,解决不了就禁止了。
如果真要我解释:(a++)是一个“没地址的临时变量”的话,那根据上面的过程,我更愿意相信这个“临时变量”根本没存在过。
如果在寄存器eax中的值算临时变量的话,那它其实还是原值,而不是自加1以后的值。
归根结底,那是C语言的定义,“左值返回地址”、”右值是无地址的表达式“。一旦不在C语言层面看,很多东西都颠覆了,所以也不好这样论,C语言中的定义还按C语言的走吧,他说怎么算左值怎么算吧,知道实现过程就行了。
目前为止至少可以说,在这个环境下,以我通过a、b发现的规律来推测,C选项的“参考答案”是错误的:
C选项应该是a*2 == 8以后再自加1,应该是9;
而D选项,如果可以的话,可能是:a先自加1变5,5*2 == 10以后,10再自加1变11。
但这都是推测,不执行就不敢确认,况且人家的自加1都是在“=”左边,我使用的a和b都是在“=”右边的情况,说不定会有特例。。。
以我的这个环境还真的没法测出来!遗憾,暂时不能完美解决这个问题。
还有很多要注意的事,比如,C和C++ 是不一样的,C在不同的系统和不同的编译器下,结果也不同:
最后加几个常见的小例子的分析:
#include<stdio.h> main(){ int a = 1; // a = a +++++ a;//估计和下边带括号的执行顺序一样。 a = a++ + ++a; // a = a + (++(++a));//前边也提到我的gcc是不允许++a当左值的,所以这种也不用试了 printf("%d\n",a); } ~
//如果写成a = a +++++ a;会编译出错。
root@v:/usr/local/C-language# gcc apppppa.c
apppppa.c: In function ‘main’:apppppa.c:5:10: error: lvalue required as increment operand
修改后。root@v:/usr/local/C-language# gcc apppppa.c
root@v:/usr/local/C-language# ./a.out
5
很特别的一点就是,”a+++++a“中,并不是编译器简单的算顺序结合,此处空格很重要,能改变性质。
结果呢,没什么好说的,先+1变成2,然后2+2变成4,最后+1变成5,下面是过程。0x80483f5 <main+17>: addl $0x1,0x1c(%esp) 0x80483fa <main+22>: mov 0x1c(%esp),%eax 0x80483fe <main+26>: add %eax,%eax 0x8048400 <main+28>: mov %eax,0x1c(%esp) 0x8048404 <main+32>: addl $0x1,0x1c(%esp)
有人的机子号称跑出了4的结果,还是GCC,可惜没说什么版本,多少位。即使不知道自己的GCC什么版本,不知道自己系统的汇编怎么一个过程,他也能解释得跟结果一样:
a = a++ + ++a;
他的过程是a++的结果是1。然后++a时a初始是2,++后变成3。结果就是a=1 + 3也就是4。
在第三个加号之前,也就是说a++在式子中就已经生效了,那还要++a干嘛,所以这种事,有点马后炮的感觉,你根据你机子的结果,猜测这个结合过程和顺序,这完全没有任何意义,没有机子让你说,那就没结论了。
毕竟也出现了结果4,也许,他把表达式写在printf里了——那4就很好解释了。。。
或者,过去的GCC是那样的,毕竟我这个版本已经不允许++a当左值了,而且很多人都说有,那估计是有过。
没机会推翻它,保留意见。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。