剖析C语言中a=a+++++a的无聊问题

原创 2013年12月05日 20:43:31
今天中午在QQ群里和同僚们闲聊,突然就聊到了a+++++a的问题。这种纯属C语言 “二” 级的问题应该是从a+++a引申出来的吧。于是乎兄弟姐妹们开始讨论它的运算结果,以及改如何理解。更有人写出(a++)+(++a)   a+(++(++a)) ((a++)++)+a这样的东西,问应该如何计算。我表示鸭梨很大...


针对这样的问题我的观点是,“绝不小心求证,只管大胆胡说!” 哈哈,当然了,我还是要对我的师兄弟们负责的,所以我下面的“胡说”中会尽量有理有据。


看法一:

a=a+++++a这个东西可以用来讨论,甚至是讨论它的无所事处,作为增长知识和发现自身理解问题的漏洞是可以的。但是绝对不能拿来作为考试题目,特别是选择题或填空题等客观题目。但是如果作为一道主观探讨题还是挺有趣的,理解深刻的人一定可以写的很好。


看法二:

a=a+++++a的编译和执行结果是随机的,可能有些屌丝编译器自认为自己很牛,可以处理这样的语句,并把它编译出来而不报任何警告。那么我首先建议这样的编译器别用了,其次我要说这个东西的编译结果并不重要,重要的是千万不要在项目代码中这样写。


下面让我们来看一下试验:

试验环境:

发行版:

[zorro@dhcp-65-110 tmp]$ cat /etc/issue
Fedora release 19 (Schrödinger’s Cat)
Kernel \r on an \m (\l)

内核和体系结构:

[zorro@dhcp-65-110 tmp]$ uname -a
Linux dhcp-65-110.nay.redhat.com 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

编译器:
[zorro@dhcp-65-110 tmp]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131017/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131017/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC)


为什么要列这么详细?因为我想告诉你,细微的一个编译gcc时使用的编译选项的差别都有可能导致使用gcc时编译结果的不一样。

在Linux系统中,每个软件基本都是通过三个基本步骤从源代码到安装进系统运行的。这三个步骤是:

configure

make

make install

比如configure时的不同选项和参数会决定代码编译出来的软件的不同特征。好了,这里不多说这个,言归正传。写一个简单的程序用来测试:

#include <stdio.h>
int main(){
    int a = 1;
    a = a+++++a;
    printf("a=%d\n", a);
    return 0;
}

我们来在上面说的环境下用gcc编译看看:

[zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall
testcode.c: 在函数‘main’中:
testcode.c:5:9: 错误:自增操作数必须是左值
  a = a+++++a;
               ^

好吧,倒霉的中文翻译让人看不懂,我们改成英文重新来一下:

[zorro@dhcp-65-110 tmp]$ LANG=C
[zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall
testcode.c: In function 'main':
testcode.c:5:9: error: lvalue required as increment operand
  a = a+++++a;
               ^

好了,这回看懂了,意思是说++这个自增操作需要一个左值。这么说的话编译器可能是这样理解的:

a=((a++)++)+a;或者a=a+(++(++a));

让我们分别改成这两种情况尝试一下:

编译a = ((a++)++)+a的结果是:

[zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall
testcode.c: In function 'main':
testcode.c:5:12: error: lvalue required as increment operand
  a = ((a++)++)+a;
                  ^

编译a = a+(++(++a))的结果是:

[zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall
testcode.c: In function 'main':
testcode.c:5:9: error: lvalue required as increment operand
  a = a+(++(++a));
              ^
和写成a = a+++++a的编译错误差不多。这就是说我的gcc认为++操作是不能以++a或者a++作为操作数的。


再看一下这样写:

a=a++ + ++a

请严重注意在中间那个+两边各有一个空格,让我们编译一下:

[zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall
testcode.c: In function 'main':
testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point]
  a = a++ + ++a;

testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point]

这次没有error发生,只有两个警告。这样应该编译出可执行文件mytest了。先不管这两个警告我们执行一下看看:

[zorro@dhcp-65-110 tmp]$ ./mytest
a=4

嗯,看来a=1;a=a++ + ++a是这样做的:

a++的结果是1。然后++a时a初始是2,++后变成3。结果就是a=1 + 3也就是4。


虽然是编译出来了,并且也执行了,但是这样好吗?对,当然是不好。光那两个警告摆在那就够让人提心吊胆了。那个警告的意思是在说a上的操作可能是没有明确定义的,好像听着很晦涩难懂。好吧,我翻译成21世纪现代汉语告诉,它的意思的:我劝你别这么干,你要是非要这么干,到执行时别怪我跟你玩虚的。


有人说我用括号让意思明确一些应该行了吧?编译一下看看:

[zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall
testcode.c: In function 'main':
testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point]
  a = (a++) + (++a);

testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point]


唉,看来还是不行。为什么呢?我个人的理解是编译器可能想告诉你加法运算符的左右两边如果都是算式,那么不一定哪边先被执行。也就是加法运算符的左右两个操作数不一定谁先被读取执行,那么当左右两个运算又相互耦合时,聪明的编译器就会告诉你千万别这么干。你这么干了在我这可能是一种结果,在别的地方可能就是另一种结果了,但是不能完全指望编译器帮你检查出来,上面如果我们把-Wall选项去掉再编译,那么就不会有这个警告了,或者有的编译器目光狭窄根本不认为这是个问题,那么问题就非常严重了。如果是一个几万行几十万行甚至更多行的项目,这样的问题是很难调式发现的。所以千万要注意!


我们来总结一下,上面说了两个重要的问题:

1、++运算符不能以++a或a++作为运算数,至少在gcc上不让这样,所以建议你别这样写。

2、一些多目运算符号(如加减乘除与或等),多个运算数如果是表达式,特别是耦合关系很强的表达式,千万要分开顺序重新组织代码,否则你不知道它先让哪个执行。


对于第二点可以扩展到函数等地方,例如printf()函数,很多人喜欢在printf里写表达式,如:

printf("%d,%d,%d", 表达式1,表达式2,表达式3);

当这3个表达式的执行顺序很重要时,你千万不要自认为它一定是按照1,2,3的顺序运行,它有可能是3,2,1的顺序的。

类似的地方还有很多,要时刻注意代码安全的重要性。

 

版权声明:本文为博主原创文章,未经博主允许不得转载。

剖析C语言中a=a+++++a的无聊问题

同僚们闲聊,突然就聊到了a+++++a的问题。这种纯属C语言 “二” 级的问题应该是从a+++a引申出来的吧。于是乎兄弟姐妹们开始讨论它的运算结果,以及改如何理解。更有人写出(a++)+(++a) a...

周末无聊写的一个C语言双色球选号程序

功能描述: 程序每执行一次将会输出16组号码,篮球号码依次为01到16。红球的特征:红球区的33个号码在16 * 6个数字中 有30个会出现3次,有3个会出现2次。 如下: 07 10 11 27 ...

C语言大小端问题剖析

在C语言中,常常会遇到判断CPU大小端的问题,在很多的笔试面试中经常会出现类似的题目,网络编程中也会进程遇到类似的问题,此文做以总结。 1、那么何为CPU的大端和小端呢? 大端: 指的...

因为对Perl和Python不满?圣诞节无聊?编程语言的出现都这么随意吗?

A.1. 第一个计算机语言:Fortran  Fortran I 诞生于 1957 年,由 IBM 设计,是世界上第一个真正的计算机语言。 Fortran I 运行于 IBM ...

C 语言程序设计实践 8.8 W.C之无聊的游戏

AC代码: #include void Converse(int R[],int n,int p); void Reverse(int R[], int from, int to); ...

初学shell,今天遇到由wget下载到本地的网页源代码的乱码问题,无聊的写了一个转码的脚本

今天用wget想下载文件,结果下载了一堆本地的index.html文件,一查看全是乱码,然后百度了一下,网页的编码格式大概有三种: 1、utf-8 2、gb2312 3、gbk 要在网页源码中...

算法提高 排队打水问题 无聊刷个水题

算法提高 排队打水问题 时间限制:1.0s 内存限制:256.0MB 提交此题 问题描述   有n个人排队到r个水龙头去打水,他们装满水桶的时间t1、t2………..tn为整数且各不相等,应...

面试必问的7大“无聊”问题

别武断地觉得面试官在面试中经常问一些很“没个性”的问题,其实,这些问题是必须要问的,其用意让我慢慢道来:   请介绍一下你自己   自我介绍不是目的,而是手段。让应聘者做自我介绍,并不...

无聊之作:幻方问题 ( 全 )

闲来无聊。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。   >>>>>>>>>>>>>>>>>>>>>>>>>>>>幻方大全>>>>>>>>>>>>>>>>>>>...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:剖析C语言中a=a+++++a的无聊问题
举报原因:
原因补充:

(最多只允许输入30个字)