表达式在C++中没有副作用

Question

看,我没有得到的,为什么像以下这样的程序是合法的？

int main()
{ 
    static const int i = 0;
    i < i > i;
}

我的意思是,当然,没有人真正拥有任何当前具有无副作用的表达式的程序,因为这将是非常无意义的,并且它将使解析和编译语言变得更加容易.那么为什么不禁止它们呢？允许这种语法,语言实际上有什么好处？

另一个例子是这样的:

int main() {
    static const int i = 0;
    int x = (i);
}

这些陈述的实际好处是什么？

像最令人烦恼的解析之类的东西.是否有人在其他功能中声明功能？我的意思是,我们摆脱了隐式函数声明之类的东西,以及类似的东西.为什么不为C++ 0x删除它们？

Answer 1

可能因为禁止会使规范更复杂,这会使编译器更复杂.

Answer 2

它将使解析和编译语言变得更加容易

我不明白怎么办。为什么i < i > i如果您需要发出诊断，那么解析和编译会比如果您被允许做任何您该死的事情而解析它更容易，前提是发出的代码没有副作用？

Java 编译器禁止无法访问的代码（而不是没有效果的代码），这对程序员来说是一件好事，并且需要编译器比 C++ 编译器实际需要做的事情做一些额外的工作（基本的块依赖）分析）。C++ 应该禁止无法访问的代码吗？可能不会。尽管 C++ 编译器确实做了足够的优化来识别无法访问的基本块，但在某些情况下它们可能会做得太多。如果是错误的编译时常量，则应该if (foo) { ...}是非法的无法访问的块？foo如果它不是编译时常量，但优化器已经弄清楚如何计算该值，它是否合法，并且编译器必须意识到删除它的原因是特定于实现的，以免给出错误，该怎么办？更多特殊情况。

目前没有人真正拥有任何包含没有副作用的表达式的程序

负载。例如，如果NDEBUG为 true，则assert扩展为 void 表达式，但没有任何效果。因此，编译器需要更特殊的情况来允许一些无用的表达式，但不允许其他表达式。

我认为，其基本原理是，如果它扩展到什么都没有，那么（a）编译器最终会抛出诸如 之类的警告if (foo) assert(bar);，并且（b）这样的代码在发布中是合法的，但在调试中不合法，这只是令人困惑：

assert(foo) // oops, forgot the semi-colon
foo.bar();

像最令人烦恼的解析之类的事情

这就是为什么它被称为“烦恼”。这确实是一个向后兼容性问题。如果 C++ 现在改变了那些令人烦恼的解析的含义，现有代码的含义也会改变。正如您所指出的，现有代码不多，但 C++ 委员会在向后兼容性方面采取了相当强硬的立场。如果您想要一种每五分钟更改一次的语言，请使用 Perl ;-)

无论如何，现在已经太晚了。即使我们有一些 C++0x 委员会错过的深刻见解，为什么某些功能应该被删除或不兼容地更改，它们也不会破坏 FCD 中的任何内容，除非 FCD 明确是错误的。

请注意，对于您的所有建议，任何编译器都可以向它们发出警告（实际上，我不明白第二个示例的问题是什么，但肯定是针对无用的表达式和函数体中令人烦恼的解析）。如果你是对的，没有人故意这样做，那么警告不会造成任何伤害。如果你错误地认为没有人故意这样做，那么你所说的删除它们的理由是不正确的。流行编译器中的警告可能为删除功能铺平道路，特别是因为该标准主要是由编译器编写者编写的。事实上，我们并不总是收到这些事情的警告，这一事实对我来说表明事情比你想象的要多。