int main()
{
static const int i = 0;
i < i > i;
}
我的意思是,当然,没有人真正拥有任何当前具有无副作用的表达式的程序,因为这将是非常无意义的,并且它将使得解析和编译语言更容易.那么为什么不禁止它们呢？允许这种语法,语言实际上有什么好处？
另一个例子是这样的：
int main() {
static const int i = 0;
int x = (i);
}
这些陈述的实际好处是什么？
像最令人烦恼的解析之类的东西.是否有人在其他功能中声明功能？我的意思是,我们摆脱了隐式函数声明之类的东西,以及类似的东西.为什么不为C 0x摆脱它们？
解决方法
it would make parsing & compiling the
language much easier
我不知道怎么样.为什么解析和编译i<我>我,如果你被要求发出诊断,那么如果你被允许做任何你该做的事情就解析它,只要你发出的代码没有副作用？
Java编译器禁止无法访问的代码(而不是无效的代码),这对于程序员来说是一个喜忧参半的祝福,并且需要编译器的一些额外工作,而不是C编译器实际需要做的事情(基本块依赖性)分析). C应该禁止无法访问的代码吗？可能不是.尽管C编译器确实做了足够的优化来识别无法访问的基本块,但在某些情况下它们可能会做得太多.如果foo是一个错误的编译时常量,if if(foo){…}是非法无法访问的块吗？如果它不是编译时常量,但优化器已经弄清楚如何计算该值,如果它是合法的并且编译器必须意识到它删除它的原因是特定于实现的,以免出错？更特殊的情况.
nobody actually has any current
programs that have expressions with no
side effects in them
负载.例如,如果NDEBUG为true,则assert扩展为void表达式而不起作用.因此,编译器需要更多特殊情况来允许一些无用的表达式,而不是其他表达式.
我认为,理由是,如果它扩展到无,那么(a)编译器最终会抛出if(foo)assert(bar);和(b)这样的代码在释放时合法的警告但不是在调试中,这只是令人困惑：
assert(foo) // oops,forgot the semi-colon foo.bar();
things like the most vexing parse
这就是为什么它被称为“烦恼”.这真的是一个向后兼容的问题.如果C现在改变了那些烦恼的解析的含义,现有代码的含义就会改变.正如您所指出的那样,现有的代码并不多,但C委员会在向后兼容性方面采取了相当强的措施.如果您想要一种每五分钟更改一次的语言,请使用Perl
