代码之家 › 专栏 › 技术社区 › Zebrafish

当一个数字文字是参数时,C++最麻烦的解析是什么?[副本]

most-vexing-parse ambiguous c++

0

Zebrafish · 技术社区 · 6 年前

我在上这样的课:

struct InputHandler
{
    std::vector<std::pair<int, int>> keyBindings( 256 );
};

它出现了一个错误,我知道这是因为编译器将其解释为函数,而不是构造函数参数。但我想知道,当我在括号中传递一个数字文字时,是否有任何含糊不清的地方,比如在本例中?我知道我可以通过在这里使用花括号来解决这个问题,但我认为不会出现最令人烦恼的解析问题,因为使用256的数字文字不能解释为函数。

编辑:我很高兴关闭或删除此问题。我学到的是,尽管这一行并不含糊,但C++11的一般规则禁止在类中使用除=或{}以外的任何其他初始值设定项,这是一条一般规则,以免对该规则有额外的例外。另一方面,在main()函数中创建向量为:

std::vector<std::pair<int, int> foo(5);

工作正常。显然,这不是一个模棱两可的表达。

2 回复 | 直到 6 年前

1

4

user9160056 6 年前

但我认为最令人烦恼的解析问题不会出现,因为使用256的数字文字不能解释为函数。

这是正确的,它不是最令人烦恼的解析。最麻烦的解析是在 [dcl.ambig.res] :

由于函数样式转换和[stmt.ambig]中提到的声明之间的相似性而产生的歧义也可能发生在声明的上下文中。在这种情况下,可以在参数名称周围有一组冗余括号的函数声明和以函数样式转换为初始值设定项的对象声明之间进行选择。正如[stmt.ambig]中提到的模糊性一样,解决方案是考虑任何可能是声明的构造。

这里的问题是,您不能使用初始化成员 () 只有 = 或 {} ,因此,歧义解决方案自然不适用。

2

StoryTeller - Unslander Monica 6 年前

但我想知道,当我在括号中传递一个数字文字时,是否有任何含糊不清的地方,比如在本例中?

可能不会,但这会使语法更加复杂。默认成员初始值设定项只支持统一初始化和复制初始化,因为这些东西不可能出现在现有代码中。而且很容易将它们与函数声明区分开来。

正在添加 另一个 括号的重载使用从来都不是一个目标。在我看来,它被过度使用了。如果它在一般情况下不受支持,那么仅为您想到的这个特定用例支持它几乎不是一个值得进行语法扭曲的有用特性。