为什么缩小不影响重载解析？

Question

请考虑以下情况:

struct A {
    A(float ) { }
    A(int ) { }
};

int main() {
    A{1.1}; // error: ambiguous
}

这将无法编译，并出现关于< code>A::A的不明确重载的错误。两个候选人都被认为是可行的，因为要求很简单:

其次，为了使 F 成为一个可行的函数，每个参数都应该存在一个隐式转换序列 （13.3.3.1），该序列将该参数转换为 F 的相应参数。

虽然有一个从＜code＞double＜/code＞到＜code＞int＜/code＞的隐式转换序列，但＜code＞A（int）＜/code>重载实际上是不可行的（在规范的非C标准意义上），这将涉及一个窄化转换，因此是病态的。

为什么在确定可行的候选人的过程中没有考虑缩小转换范围？是否有任何其他情况，尽管只有一个候选人可行，但过载被认为是模棱两可的？

Answer 1

>

缩小是编译器只知道内置类型的事情。用户定义的隐式转换不能标记为缩小或不缩小。

缩小转化范围首先不应被允许隐式进行。（不幸的是，它是C兼容性所必需的。这已通过 {} 初始化进行了一定程度的纠正，该初始化禁止对内置类型进行缩小。

考虑到这些，重载规则不必提及这种特殊情况是有道理的。这可能只是偶尔的方便，但也不是那么有价值。在我看来，一般来说，在重载解析中涉及的因素越少越好，而拒绝更多模糊的内容，迫使程序员显式解析这些内容。

此外，双精度到浮点数是当双精度不是常量表达式或双精度太大时的缩小转换。

#include <iostream>
#include <iomanip>

int main() {
    double d{1.1};
    float f{d};
    std::cout << std::setprecision(100) << d << " " << f << '\n';
}

这通常会产生错误：

main.cpp:7:13: error: non-constant-expression cannot be narrowed from type 'double' to 'float' in initializer list [-Wc++++11-narrowing]
    float f{d};
            ^

Answer 2

问题在于可以检测到不基于类型的缩小转换。

在C中编译时生成值的方法非常复杂。

阻止缩小转换范围是一件好事。使C的重载分辨率比现在更复杂是一件坏事。

在确定重载分辨率时忽略窄化转换规则（这使得重载分辨率完全与类型有关），然后在选定的重载导致窄化转换时出错，可以避免重载分辨率变得更复杂，并以某种方式检测和防止窄化转换。

只有一个候选项可行的两个示例是在实例化期间“延迟”失败的模板函数，以及副本列表初始化（其中考虑显式构造函数，但如果选择了它们，则会收到错误）。同样，具有这种影响过载分辨率将使过载分辨率比现在更加复杂。

现在，有人可能会问，为什么不将缩小转换纯粹折叠到类型系统中呢？

使窄化转换完全基于类型是不可行的。这样的更改可能会破坏编译器可以证明有效的大量“遗留”代码。当大多数错误都是实际错误，而不是新的编译器版本是一个错误时，清理代码库所需的努力就更有价值了。

unsigned char buff[]={0xff, 0x00, 0x1f};

这在基于类型的缩小转换下会失败，因为0xff是int类型的，并且这样的代码非常常见。

如果这样的代码需要对int文本进行毫无意义的修改，那么扫描很可能会以我们设置一个标志来告诉编译器对愚蠢的错误闭嘴而告终。