为什么a = i + i ++未定义而不是未指定的行为 [英] Why is a = i + i++ undefined and not unspecified behaviour

问题描述

我阅读了关于未定义的行为和序列点的几个非常好的答案（例如未定义的行为和序列点），我理解

I read through several very good answers about undefined behaviour and sequence points (e.g. Undefined Behavior and Sequence Points) and I understand, that

   int i = 1;
   a = i + i++; //this is undefined behaviour

是未定义的代码，根据C ++标准。但是，它背后的更深层次的理由是未定义的行为？它不足以使其未指定的行为？
正常的参数是，通过几个序列点，C ++编译器可以更好地优化不同的架构，但不会离开它未指定允许这些优化？在

is undefined code, according to the C++ standard. But what is the deeper reasoning behind it being undefined behaviour? Wouldn't it be enough to make it unspecified behaviour? The normal argument is, that by having few sequence points, C++ compilers can optimize better for different architectures, but wouldn't leaving it unspecified allow those optimizations as well? In

   a = foo(bar(1), bar(2)); //this is unspecified behaviour

编译器也可以优化，而不是未定义的行为。在第一个例子中，很明显，a是2或3，所以语义似乎对我很清楚。

the compiler can also optimize, and it is not undefined behaviour. In the first example it seems clear, that a is either 2 or 3, so the semantics seems to be clear to me. I hope there is a reasoning, why some things are unspecified, and others are undefined.

推荐答案

从C ++的角度来看，我认为这是一个非常重要的事情。认为答案是令人难以置信的简单：它是做不明确的行为，因为C很久以前它是未定义的行为，从本质上没有改变的潜在收益。

From the viewpoint of C++, I think the answer is incredibly simple: it was made undefined behavior because C had made it undefined behavior long before, and there was essentially no potential gain from changing that.

我想的是更多的意图的问题：为什么C做这个未定义的行为？

That points to what I'd guess was really more the intended question: why did C make this undefined behavior?

我不认为这是一个简单的答案。一种可能性是简单的谨慎 - 知道在C标准被编写的时候，C已经被实现，部署并在许多机器上使用。相当多的机器，然后看起来像很多代码我仍然看到：最初设计只是作为一个个人的实验，工作得很好，它最终被指定为生产，甚至没有一个令人意外的尝试修复任何东西最严重的问题。因此，即使没有人知道硬件会破裂，没有人真的可以确定这样的硬件也不存在，所以它是最安全的，只是调用它UB，并完成它。

I don't think that has quite as simple of an answer. One possibility is simple caution -- knowledge that by the time the C standard was being written, C had already been implemented, deployed and used on lots of machines. A fair number of machines back then seemed like a lot of code I still see: something originally designed only as a personal experiment, that worked well enough that it ended up designated as "production", without even a token attempt at fixing anything by the most egregious problems. As such, even if nobody knew of hardware this would break, nobody could be really sure such hardware didn't exist either, so it was safest to just call it UB, and be done with it.

另一个可能性是，它有点超出了简单的谨慎。即使我们可以用现代硬件感到相当安全，可能有硬件，当时人们真正知道会有这方面的主要问题，（特别是如果供应商与该硬件在委员会代表）允许C运行

Another possibility is that it went a bit beyond simple caution. Even though we can feel fairly safe with modern hardware, there may have been hardware at the time that people really knew would have major problems with this, and (especially if vendors associated with that hardware were represented on the committee) allowing C to run on that hardware was considered important.

然而，另一种可能性是，即使没有人知道（或者甚至担心）一些现有的实现，这可能会打破，他们预见未来的可能性，它会破坏的东西，所以未定义的行为被视为未来的一种方式，至少在一定程度上证明语言。

Yet another possibility would be that even though nobody knew of (or even feared the possibility of) some existing implementation that this could break, they foresaw the future possibility of something it would break, so undefined behavior was seen as a way of future proofing the language to at least some limited degree.

最后的可能性是，无论谁正在写该标准的那部分，一旦他们想出了一组似乎可以接受的规则，尽管他们可能已经提出了其他规则，至少有一些可能有喜欢更好。

A final possibility is that whoever was writing that part of the standard moved on to other things as soon as they came up with a set of rules that seemed acceptable, even though they could have come up with other rules that at least some might have liked better.

如果我不得不猜测，我会说这可能是我给出的第三和第四种可能性的结合 - 委员会知道并行计算的发展，而不知道它到底如何工作，所以对于谁写的这一点，最大化的纬度在实施方面似乎是获得共识的最简单/最简单的途径，以便他们可以完成它，并移动到更大，更好的东西。

If I had to guess, I'd say it was probably a combination of the third and fourth possibilities I've given -- the committee was aware of developments in parallel computing without knowing how it would work out in the end, so for whomever wrote this, maximizing latitude on the part of the implementation seemed like the easiest/simplest route to gaining consensus so they could finish it and move on to bigger and better things.

这篇关于为什么a = i + i ++未定义而不是未指定的行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！