同僚们闲聊，突然就聊到了a+++++a的问题。这种纯属C语言 “二” 级的问题应该是从a+++a引申出来的吧。于是乎兄弟姐妹们开始讨论它的运算结果，以及改如何理解。更有人写出(a++)+(++a) a+(++(++a)) ((a++)++)+a这样的东西，问应该如何计算。我表示鸭梨很大...
本文引用地址：http://www.eepw.com.cn/article/198269.htm
针对这样的问题我的观点是，“绝不小心求证，只管大胆胡说!” 哈哈，当然了，我还是要对我的师兄弟们负责的，所以我下面的“胡说”中会尽量有理有据。
看法一：
a=a+++++a这个东西可以用来讨论，甚至是讨论它的无所事处，作为增长知识和发现自身理解问题的漏洞是可以的。但是绝对不能拿来作为考试题目，特别是选择题或填空题等客观题目。但是如果作为一道主观探讨题还是挺有趣的，理解深刻的人一定可以写的很好。
看法二：
a=a+++++a的编译和执行结果是随机的，可能有些屌丝编译器自认为自己很牛，可以处理这样的语句，并把它编译出来而不报任何警告。那么我首先建议这样的编译器别用了，其次我要说这个东西的编译结果并不重要，重要的是千万不要在项目代码中这样写。
下面让我们来看一下试验：
试验环境:
发行版：
[zorro@dhcp-65-110 tmp]$ cat /etc/issue
Fedora release 19 (Schrödinger’s Cat)
Kernel
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
int main(){
int a = 1;
a = a+++++a;
printf("a=%d
", 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选项去掉再编译，那么就不会有这个警告了，或者有的编译器目光狭窄根本不认为这是个问题，那么问题就非常严重了。如果是一个几万行几十万行甚至更多行的项目，这样的问题是很难调式发现的。所以千万要注意!
来源：电子产品世界网
作者：RedHatter