C FAQ 3.1 [英] C FAQ 3.1
问题描述
大家好，
在CFAQ 3.1中，它说：
答：在我的编译器下，代码
int i = 7;
printf（"％d \ n"，i ++ * i ++）;
打印49.无论评估顺序如何，不应该打印
56？
问：... K& R中的语言表明这个表达的行为
未指定，C标准更强烈声明它是未定义的......
我认为这很有趣。我们可以使用哪些指标来确定它
未定义或未指定？类似的情况是：
f（a ++，a）;
人们说函数参数的评估顺序是
undefined。为什么不能指明呢？
ccwork写道：大家好，
答：在我的编译器下，代码
int i = 7;
printf（"％d \ n"，i ++ * i ++）;
打印49.无论评价的顺序如何，都不应该打印
56？
问：... K& R表明这个
表达式的行为是未指定的，C标准更强烈地表明它是
未定义...
我认为这很有趣。我们可以使用哪些指标来确定它
是未定义还是未指定？
任何与标准一致的指标。
类似的情况是：
f（a ++，a）;
人们说函数参数的评估顺序是未定义的。
忘记人们说什么，阅读标准所说的内容。
"评估顺序函数指示符，实际的参数中的子表达式和实际参数中的子表达式是未指定的，但在实际的
调用之前有一个序列点。
为什么不能指明？
真正的问题是：为什么要_should_指定？
-
彼得
" ccwork" < CC **** @ hotmail.com>写道：
在CFAQ 3.1中，它说：
答：在我的编译器下，代码
int i = 7;
printf（"％d \ n"，i ++ * i ++）;
打印49.无论评价顺序如何，都不应该打印56？
这很有趣，在网页版本中提问3.2。
问：... K& R中的语言表明这个表达式的行为是未指定的，C标准更强烈地表明它是未定义的......
我认为这很有趣。我们可以使用哪些指标来确定它是未定义或未指定的？类似的情况是：
如果标准说某些代码的行为未指定，那么它是未指定的
。如果标准没有定义任何行为，或者明确地说
表示行为是未定义的，那么它是未定义的。
f（a ++，a）;
<人们说，函数参数的评估顺序是未定义的。为什么不能指明？
人们说错了;评估的_order_未指定。那个调用
会调用未定义的行为，但不是因为
评估的顺序。相反，它在第一个参数中修改了一个，并且在第二个
参数中也读取了
a，而不是为了确定它的新值。 IOW，它修改了一个表达式，并在另一个
表达式中读取它，这不是第一个表达式的一部分。这没有
干预序列点。 _That_未定义。评估顺序
确实没有说明。
当您拨打代码时，差异就会发挥作用
newvalue = compute（pop（& stack），pop（& stack））;
其中compute的值取决于pop（）的顺序。这段代码
不会调用未定义的行为，因为在每次调用pop（）之前都有一个序列点
- 但是pop（）的顺序是
叫;因此，参数弹出的顺序
堆栈;因此，传递给计算机的值;并且
因此，newvalue的新值;没有具体说明。
Richard
Peter Nilsson写道：ccwork写道：
大家好，
为什么不能指定？
真实问题是：为什么_should_它被指定？
因为它会清除很多混乱，请准确指出
行为应该是什么。我确信我们有不确定的行为，因为
K& R太懒或者急着指定
这些现在未定义的情况应该发生什么。
Hi all,
In CFAQ 3.1, it says:
A: Under my compiler, the code
int i = 7;
printf("%d\n", i++ * i++);
prints 49. Regardless of the order of evaluation, shouldn''t it print
56?
Q: ...the language in K&R suggests that the behavior of this expression
is unspecified, the C Standard makes the stronger statement that it is
undefined...
I think this is interesting. What metrics can we use to determine it is
undefined or unspecified? A similar case is:
f(a++, a);
People says the order of evaluation for function arguments is
undefined. Why can''t it be unspecified?
ccwork wrote:Hi all,
In CFAQ 3.1, it says:
A: Under my compiler, the code
int i = 7;
printf("%d\n", i++ * i++);
prints 49. Regardless of the order of evaluation, shouldn''t it print
56?
Q: ...the language in K&R suggests that the behavior of this expression is unspecified, the C Standard makes the stronger statement that it is undefined...
I think this is interesting. What metrics can we use to determine it
is undefined or unspecified?
Any metric consistent with the Standard(s).
A similar case is:
f(a++, a);
People says the order of evaluation for function arguments is
undefined.
Forget what ''people'' say, read what the Standard(s) say.
"The order of evaluation of the function designator, the actual
arguments, and subexpressions within the actual arguments is
unspecified, but there is a sequence point before the actual
call."
Why can''t it be unspecified?
The real question is: Why _should_ it be specified?
--
Peter
"ccwork" <cc****@hotmail.com> wrote:
In CFAQ 3.1, it says:
A: Under my compiler, the code
int i = 7;
printf("%d\n", i++ * i++);
prints 49. Regardless of the order of evaluation, shouldn''t it print
56?
That''s funny, in the web version that''s question 3.2.
Q: ...the language in K&R suggests that the behavior of this expression
is unspecified, the C Standard makes the stronger statement that it is
undefined...
I think this is interesting. What metrics can we use to determine it is
undefined or unspecified? A similar case is:
If the Standard says the behaviour of some code unspecified, it''s
unspecified. If the Standard doesn''t define any behaviour, or explicitly
says the behaviour is undefined, it is undefined.
f(a++, a);
People says the order of evaluation for function arguments is
undefined. Why can''t it be unspecified?
People say wrong; the _order_ of evaluation _is_ unspecified. That call
does invoke undefined behaviour, but not because of the order of
evaluation. Rather, it modifies a in the first argument, and also reads
a, not for the purpose of determining its new value, in the second
argument. IOW, it modifies a in one expression, and reads it in another
expression which isn''t part of the first one. And this without an
intervening sequence point. _That_ is undefined. The order of evaluation
is indeed unspecified.
The difference comes into play when you call code such as
newvalue=compute(pop(&stack), pop(&stack));
where the value of compute depends on the order of the pop()s. This code
does not invoke undefined behaviour, because there''s a sequence point
just before each call of pop() - but the order in which the pop()s are
called; and therefore, the order in which the arguments are popped off
the stack; and therefore, the values that get passes to computer; and
therefore, the new value of newvalue; is unspecified.
Richard
Peter Nilsson wrote:ccwork wrote:Hi all,
Why can''t it be unspecified?
The real question is: Why _should_ it be specified?
Because it would clear up a lot of confusion, specify exactly what the
behavior should be. I am convinced we have undefined behavior because
K&R were too lazy or in a hurry to specify exactly what should happen in
these now undefined cases.
这篇关于C FAQ 3.1的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
