关于C和评估顺序 [英] About C and order of evaluation
问题描述
您好，在以下程序中：
#include< stdio.h>
int main（void）{
int x = 1，y = 2，z;
z = x +++ y;
返回0;
}
执行后，z的值为3，x为2，y为2.
有人可以请详细解释为什么它被
编译器视为（x ++）+ y而不是例如x +（++ y）？
编译器的步骤是否能产生这样的结果？
感谢您的时间和对不起我的坏英语
Charalampos Pournaris
Richard Heathfield写道：
因此，z = x +++ y;被解析为
[z] [=] [x] [++] [+] [y] [;]
编译器可能对该代码感到满意，但我肯定不会高兴
如果它出现在我必须维护的程序中。它_looks_就像一个错字，
并且没有分析周围的线条，就没有办法判断：
z =（x ++）+ y; < br $>
或
z = x +（++ y）;
是有意的。这是另一个例子，其中C
对于它将接受的语法有点过于灵活（根据我的口味）。
有时如果编译器会更好警告
程序员加入更多的空格或括号，以便代码的含义明确无误。这是毫不含糊的，没有
必须知道关于编译器的解析器
如何运行的神秘细节。
这里'所有额外的Hello World空格和EOL被删除。
它只有3行和两个空格：一个在int之间。和主要
和Hello之间的一个和世界。我的新闻客户端在
之后包装了第二个空格，但原来它只是一个3行程序。
#include< stdlib.h>
#include< stdio.h>
int main（void）{（void）fprintf（stdout，" Hello
world \ n"）;（void）退出（EXIT_SUCCESS）;}
这3行形式是合法的，但它也很难阅读。如果gcc（例如）至少有一个可选的-Whuman，它会发出
警告，因为难以阅读但是其他合法的结构。
会很好。
问候，
David Mathog
David Mathog写道：
Richard Heathfield写道：
>因此，z = x +++ y;被解析为
[z] [=] [x] [++] [+] [y] [;]
编译器可能对该代码感到满意，但我肯定不会很高兴
如果它出现在我必须维护的程序中。它_looks_就像一个
错字，如果没有分析周围的线条，就没有办法
判断：
z =（x ++）+ y;
或
z = x +（++ y）;
是有意的。这是另一个例子，其中C
对于语法来说有点过于灵活（根据我的口味）它会接受
接受。
有时，如果编译器警告
程序员增加一些空格或括号，以便代码的含义明确无误，那就更好了。这是明确的，没有
必须知道有关编译器的解析器
如何运行的神秘细节。
教授编程最佳编码
做法并不是编译器的工作。没有人阻止某人写清楚，格式良好的
来源。不幸的是，太多的C程序员都有IOCCC的野心。
见证最近由Antoninus Twink发起的主题抱怨
a明确的C代码。
这里是'Hello World with allextra空格和EOL被删除。
它只有3行和两个空格：一个在int之间。和主要
和Hello之间的一个和世界。我的新闻客户端在第二个空格后包裹了这个
，但在原来它只有3行
程序。
＃ include< stdlib.h>
#include< stdio.h>
int main（void）{（void）fprintf（stdout，" Hello
world \ n"）;（void）退出（EXIT_SUCCESS）;}
这3行形式是合法的，但它也很难阅读。如果gcc（例如）至少有一个可选的-Whuman，
会发出难以阅读但其他合法结构的警告，那么这将是好的。
这是一个主观决定，我认为，虽然我不确定，但是很难实现
。这是程序员必须从好书和同行那里学习的东西，而不是编译器，恕我直言。
David Mathog写道：
Richard Heathfield写道：
>因此，z = x +++ y;被解析为
[z] [=] [x] [++] [+] [y] [;]
编译器可能对该代码感到满意，但我肯定不会高兴
如果它出现在我必须维护的程序中。
"它是指定的。但是那些编写这样代码的人应该将trans $变成蚯蚓变成蚯蚓并喂给鸭子。
我找不到原始的，只有回声在标志性的引用中，唉。
-
Chris" transmogrified ducks dollin" Dollin
Hewlett-Packard Limited注册号：
注册办事处：Cain Road，Bracknell，Berks RG12 1HN 690597英格兰
Hello, in the program below:
#include <stdio.h>
int main(void) {
int x = 1, y = 2, z;
z = x+++y;
return 0;
}
after executing, z has the value of 3, x is 2 and y is 2.
Can someone please explain me in detail why it is treated by the
compiler as (x++)+y and not for example as x+(++y) ?
What steps the compiler does to produce that result ?
Thanks for your time and sorry for my bad english
Charalampos Pournaris
Richard Heathfield wrote:
Thus, z = x+++y; is parsed as
[z] [=] [x] [++] [+] [y] [;]The compiler may be happy with that code but I sure wouldn''t be pleased
if it showed up in a program I had to maintain. It _looks_ like a typo,
and without analyzing the surrounding lines there''s no way to tell if:
z = (x++)+y;
or
z = x+(++y);
was intended. This is another one of those instances where C
is a little too flexible (for my taste) about the syntax it will accept.
Sometimes it would be better if the compilers warned the
programmers to put in a few more spaces or parentheses so that the
meaning of the code would be unambiguous. That is unambiguous without
having to know arcane details about the how the compiler''s parser
functioned.
Here''s Hello World with all "extra" spaces and EOL''s removed.
It''s down to just 3 lines and two spaces: one between "int" and "main"
and one between "Hello" and "world". My news client wrapped this after
the second space but in the original it was only a 3 line program.
#include <stdlib.h>
#include <stdio.h>
int main(void){(void)fprintf(stdout,"Hello
world\n");(void)exit(EXIT_SUCCESS);}
This 3 line form is legal but it''s also really hard to read. It would
be nice if gcc (for instance) had at least an optional -Whuman, to issue
warnings for difficult to read but otherwise legal constructs.
Regards,
David Mathog
David Mathog wrote:
Richard Heathfield wrote:
>Thus, z = x+++y; is parsed as
[z] [=] [x] [++] [+] [y] [;]
The compiler may be happy with that code but I sure wouldn''t be
pleased
if it showed up in a program I had to maintain. It _looks_ like a
typo, and without analyzing the surrounding lines there''s no way to
tell if:
z = (x++)+y;
or
z = x+(++y);
was intended. This is another one of those instances where C
is a little too flexible (for my taste) about the syntax it will
accept.
Sometimes it would be better if the compilers warned the
programmers to put in a few more spaces or parentheses so that the
meaning of the code would be unambiguous. That is unambiguous without
having to know arcane details about the how the compiler''s parser
functioned.It''s not the compiler''s job to teach the programming best coding
practices. No one prevents someone from writing clear, well formatted
source. Unfortunately too many C programmers have IOCCC ambitions.
Witness the recent thread started by Antoninus Twink complaining about
a piece of clear C code.
Here''s Hello World with all "extra" spaces and EOL''s removed.
It''s down to just 3 lines and two spaces: one between "int" and "main"
and one between "Hello" and "world". My news client wrapped this
after the second space but in the original it was only a 3 line
program.
#include <stdlib.h>
#include <stdio.h>
int main(void){(void)fprintf(stdout,"Hello
world\n");(void)exit(EXIT_SUCCESS);}
This 3 line form is legal but it''s also really hard to read. It would
be nice if gcc (for instance) had at least an optional -Whuman, to
issue warnings for difficult to read but otherwise legal constructs.This is a subjective decision and I think, though I''m not sure, it will
be rather hard to implement. This is something that the programmer must
learn from good books and peers, not a compiler, IMHO.
David Mathog wrote:
Richard Heathfield wrote:
>Thus, z = x+++y; is parsed as
[z] [=] [x] [++] [+] [y] [;]
The compiler may be happy with that code but I sure wouldn''t be pleased
if it showed up in a program I had to maintain."It''s specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks."
I can''t find the original, only echoes in sign-quotes, alas.
--
Chris "transmogrified ducks dollin" Dollin
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
这篇关于关于C和评估顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
