为什么用户定义的转换比标准整数转换更匹配？

Question

您可以在David Vandevoorde和Nicolai Josuttis的《C++模板完整指南》一书的附录B中找到下面的文本。

null

几页后，这本书展示了以下示例和文本（重点是我的）：

class BadString {
    public:
    BadString(char const*);
    ...
    // character access through subscripting:
    char& operator[] (size_t); // (1)
    char const& operator[] (size_t) const;
    // implicit conversion to null-terminated byte string:
    operator char* (); // (2)
    operator char const* ();
    ...
};
int main()
{
    BadString str("correkt");
    str[5] = 'c'; // possibly an overload resolution ambiguity!
}

起初，表达式STR[5]似乎没有任何歧义。（1）处的下标运算符似乎是一个完美的匹配。但是，它并不十分完美，因为参数5的类型是int，而运算符期望的是无符号整数类型(size_t和STD::size_t通常具有无符号int或无符号long，但绝不是int类型）。不过，一个简单的标准整数转换使（1）变得容易可行。但是，还有另一个可行的候选：内置下标运算符。实际上，如果我们将隐式转换运算符应用于str（它是隐式成员函数参数），我们将获得一个指针类型，现在应用内置下标运算符。这个内置运算符接受ptrdiff_t类型的参数，在许多平台上，该参数等效于int，因此是参数5的完美匹配。因此，即使内置的下标运算符对隐含参数的匹配很差（通过用户定义的转换），但对于实际的下标，它比在（1）处定义的运算符更好！因此潜在的模糊性。

Answer 1

注意，第一个列表是简化的重载解析。

为了删除关于int是否与ptrDiff_t相同的“可能”和“可能”，让我们更改一行：

str[(ptrdiff_t)5] = 'c'; // definitely an overload resolution ambiguity!

现在，我从g++得到的消息是：

struct S {
    explicit S(int) {}
    operator int() { return 0; }
};

void foo(const S&, long) { }
void foo(int, int) { }

int main() {
    S s(0);
    foo(s, 1);
}

现在你要向我要标准引文，但我要用我需要打干草的事实作为不查它的借口；-）

总之，这里的“用户定义的转换比标准整数转换更匹配”是不正确的。然而，在这种情况下，标准将两个可能的重载定义为同样好，因此调用是不明确的。