printf跟递增递减的运算方式问题
#include<stdio.h>void main()
{
int i = 8;
printf("%d\n%d\n%d\n%d\n%d\n%d\n",++i,--i,i++,i--,-i++,-i--);
}
得出结果是这样
8
8
7
8
-7
-8
--------------------------------
Process exited after 0.02339 seconds with return value 14
请按任意键继续 . . .
我认为是
8
7
7
8
-7
-8
我知道是从左至右的
本帖最后由 Croper 于 2019-4-18 15:03 编辑
又来了
https://fishc.com.cn/thread-132932-1-1.html
另外，c语言默认的__cdecl是从右至左的 c语言中最浪费生命力的题目 莫过于此了 {:10_266:}这个问题成功浪费了我半个小时
#include<stdio.h>
void printf_test(int i1,int i2,int i3,int i4,int i5,int i6,int i)
{
printf("i++=%d\n",i1);
printf("i++=%d\n",i2);
printf("i++=%d\n",i3);
printf("++i=%d\n",i4);
printf("i++=%d\n",i5);
printf("i++=%d\n",i6);
printf("i=%d\n",i);
}
int main (void)
{
int i = 8;
printf_test(i++,i++,i++,++i,i++,i++,i);
return 0;
}
打印结果如下：
i++=13
i++=12
i++=11
++i=14
i++=9
i++=8
i=14
我这个编译器是这样的{:10_243:}
不同编译器有不同的结果，浪费生命。。。。痛苦 本帖最后由 wwhywhy 于 2019-4-20 10:56 编辑
一点都不鱼的鱼 发表于 2019-4-18 15:35
这个问题成功浪费了我半个小时
你举的这个例子是另外一种情况。就是函数参数的赋值顺序以及如何使用该值。这个跟printf的参数的赋值顺序又不太一样。所以结果不同。
这个跟编译器没有关系。
不过你也给大家提醒了函数参数赋值这一种情况，也是非常的好！
printf（）函数的使用参数的顺序是从右到左。按照这个顺序，你就能得到计算机给你的结果。你再看看。
跟编译器没有关系的！ 本帖最后由 wwhywhy 于 2019-4-20 12:17 编辑
跟编译器没有关系的！
printf（）函数的使用参数的顺序是从右到左。
有个简单的计算方法：
printf中的只要是前置的，所有值都是一样的（是最终的变量的值）。后置的变量需要逐个计算就可以了。
int i = 8;
printf("%d\n%d\n%d\n%d\n%d\n%d\n",++i,--i,i++,i--,-i++,-i--);
1. 先都默认为是后置的，逐个计算应该显示的值： 7， 8 ，7，8，-7，-8
2. 然后将前置的值都修改为最终i的值： 8， 8
3. 最终的值就是： 8， 8 ，7，8，-7，-8 本帖最后由 Croper 于 2019-4-20 13:51 编辑
wwhywhy 发表于 2019-4-20 10:48
跟编译器没有关系的！
请问你是凭什么说这句话的？
不然你来解释一下，编译器都不用换，不同的生成选项都能出不同的结果：
https://xxx.ilovefishc.com/album/201904/20/130513l3cb07gbb0asabcc.jpg
https://xxx.ilovefishc.com/album/201904/20/130517q0jt0to4nwqjjot1.jpg
这是stackoverflow上的相关讨论
https://stackoverflow.com/questions/1270370/printfd-d-d-n-a-a-a-output
C has the concept of undefined behavior, i.e. some language constructs are syntactically valid but you can't predict the behavior when the code is run.
As far as I know, the standard doesn't explicitly say why the concept of undefined behavior exists. In my mind, it's simply because the language designers wanted there to be some leeway in the semantics, instead of i.e. requiring that all implementations handle integer overflow in the exact same way, which would very likely impose serious performance costs, they just left the behavior undefined so that if you write code that causes integer overflow, anything can happen.
So, with that in mind, why are these "issues"? The language clearly says that certain things lead to undefined behavior. There is no problem, there is no "should" involved. If the undefined behavior changes when one of the involved variables is declared volatile, that doesn't prove or change anything. It is undefined; you cannot reason about the behavior.
不懂的问题不要想当然
页:
[1]