Question

在Wikipedia我发现了这个：

A a( A() );

[This]可以作为

消除歧义


类[A]的变量定义，采用类[A]或

的匿名实例

一个函数的函数声明，它返回一个类型为[A]的对象，并获取一个（未命名的）参数，该参数是一个返回类型为[A]的函数（并且没有输入）。


大多数程序员都期望第一个，，但C ++标准要求将其解释为第二个。

但为什么呢？如果大多数C ++社区都期望以前的行为，为什么不把它作为标准呢？此外，如果您不考虑解析歧义，则上述语法是一致的。

有人可以赐教吗？为什么标准要求这个要求？

Answer 1

对于C ++，它非常简单：因为规则是用C语言制作的。

在C中，歧义只出现在typedef和一些相当模糊的代码中。几乎没有人偶然触发它 - 事实上，除了专门为证明这种可能性而设计的代码之外，它可能是罕见的。然而，无论好坏，仅仅是模糊性的可能性意味着有人必须解决它 - 如果记忆起作用，它由Dennis Ritchie解决，Dennis Ritchie下令任何可以被解释为声明的东西都是声明，即使作为定义也存在含糊不清的解释。

C ++增加了使用括号进行初始化以及将函数调用用作分组的能力，这使他将模糊性从模糊变为普通。然而，改变它将需要打破规则，因为它来自C。解决这种特殊的模糊性，正如大多数人所期望的那样，如果没有创造出更多的更令人惊讶的东西也可能是相当不平凡的，除非你愿意完全抛弃与C的兼容性。

Answer 2

我们说MVP不存在。

你会如何声明一个函数？

A foo();

将是变量定义，而不是方法声明。你会介绍一个新的关键字吗？你有一个更尴尬的函数声明语法吗？或者你愿意

A foo;

定义变量和

A foo();

声明一个函数？

您稍微复杂的例子只是为了与这个基本的一致。更容易说“可以解释为声明的所有内容，将被解释为声明”而不是“可以解释为声明的所有内容，将被解释为声明，除非它是单个变量定义，在这种情况下它是变量定义“。

这个可能并不是它背后的动机，但这是一个好事情的原因。

Answer 3

这只是猜测，但可能是因为使用给定的方法可以获得两种行为：

A a( A() ); // this is a function declaration
A a( (A()) ); // this is a variable definition

如果要将其行为更改为变量定义，则函数声明会更加复杂。

typedef A subfunction_type();

A a( A() ); // this would be a variable declaration
A a( subfunction_type ); // this would be a function declaration??

Answer 4

它的语法副作用是递归定义的。

这不是故意设计的。它被发现并记录为最令人烦恼的解析。

Answer 5

没有特别的原因，除了[可能] K-ballo识别的情况。

这只是遗产。已经存在int x;构造形式，因此当没有ctor args在场时，它似乎永远不会需要T x;。

事后我想象一下，如果语言是从今天开始设计的，那么MVP将不存在......以及大量其他C ++怪异。

回想一下，C ++ 已经发展了几十年，即使是现在，也只是由委员会设计（另见：camel）。

最令人烦恼的解析的目的是什么？

5 个答案: