为什么这里会出现这种歧义？

Question

考虑我有以下最少的代码：

#include <boost/type_traits.hpp>

template<typename ptr_t>
struct TData
{
    typedef typename boost::remove_extent<ptr_t>::type value_type;
    ptr_t data;

    value_type & operator [] ( size_t id ) { return data[id]; }
    operator ptr_t & () { return data; }
};

int main( int argc, char ** argv )
{
    TData<float[100][100]> t;   
    t[1][1] = 5;
    return 0;
}

GNU C++ 给了我错误：

test.cpp: In function 'int main(int, char**)':
test.cpp:16: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for second:
test.cpp:9: note: candidate 1: typename boost::remove_extent<ptr_t>::type& TData<ptr_t>::operator[](size_t) [with ptr_t = float [100][100]]
test.cpp:16: note: candidate 2: operator[](float (*)[100], int) <built-in>

我的问题是：

1. 为什么 GNU C++ 给出错误，而 Intel C++ 编译器却没有？
2. 为什么将operator[] 更改为以下会导致编译没有错误？

   value_type & operator [] ( int id ) { return data[id]; }

感谢 C++ 标准的链接。

---

我可以看到这里有两种转化路径：

1. (1)int 到 size_t 和 (2)operator[](size_t)。
2. (1)operator ptr_t&()、(2)int 到size_t 和(3)内置operator[](size_t)。

Answer 1

其实很简单。对于t[1]，重载决议有以下候选：

候选 1（内置：13.6/13）（T 是任意对象类型）：

• 参数列表：(T*, ptrdiff_t)

候选人 2（您的接线员）

• 参数列表：(TData<float[100][100]>&, something unsigned)

参数列表由13.3.1.2/6给出：

重载决策的候选函数集是成员候选函数、非成员候选函数和内置候选函数的并集。参数列表包含运算符的所有操作数。

• 参数列表：(TData<float[100][100]>, int)

您看到第一个参数与候选 2 的第一个参数完全匹配。但它需要对候选 1 的第一个参数进行用户定义的转换。因此对于第一个参数，第二个候选者获胜。

您还看到第二个位置的结果取决于。让我们做一些假设，看看我们得到了什么：

1. ptrdiff_t 是int：第一个候选者获胜，因为它具有完全匹配，而第二个候选者需要整数转换。
2. ptrdiff_t 是 long：两个候选人都没有获胜，因为两者都需要整数转换。

现在，13.3.3/1 说

令ICSi(F)表示将列表中的第i个参数转换为可行函数F的第i个参数的类型的隐式转换序列。

如果对于所有参数 i，ICSi(F1) 不是比 ICSi(F2) 更差的转换序列，则一个可行函数 F1 被定义为比另一个可行函数 F2 更好的函数，然后 ... 对于某个参数 j , ICSj(F1) 是比 ICSj(F2) 更好的转换序列，或者，如果不是...

对于我们的第一个假设，我们没有获得总冠军，因为候选人 2 赢得了第一个参数，而候选人 1 赢得了第二个参数。我称之为纵横交错。对于我们的第二个假设，候选 2 总体上获胜，因为这两个参数的转化率都较差，但第一个参数的转化率更好。

对于第一个假设，第二个参数中的整数转换（int 到 unsigned）与用户定义的第一个参数中另一个候选者的转换相比，这并不重要。在纵横交错中，规则是粗糙的。

---

最后一点可能会让你感到困惑，因为大家都在大惊小怪，所以让我们举个例子

void f(int, int) { }
void f(long, char) { }

int main() { f(0, 'a'); }

这给了你同样令人困惑的 GCC 警告（我记得，当我几年前第一次收到它时，它实际上把我搞糊涂了），因为 0 转换为 long 比 'a' 更糟糕int - 但你会感到模棱两可，因为你处于纵横交错的境地。

Answer 2

用表达式：

t[1][1] = 5;

编译器必须关注左侧以确定那里的内容，因此= 5; 将被忽略，直到 lhs 得到解决。给我们留下表达式：t[1][1]，它代表两个操作，第二个操作对第一个的结果进行操作，因此编译器必须只考虑表达式的第一部分：t[1]。实际类型是(TData&)[(int)]

调用与任何函数都不完全匹配，因为TData 的operator[] 被定义为采用size_t 参数，因此为了能够使用它，编译器必须将1 从int 转换到 size_t 的隐式转换。那是第一选择。现在，另一种可能的途径是应用用户定义的转换将TData<float[100][100]> 转换为float[100][100]。

int 到 size_t 转换是一个整体转换，在标准的表 9 中被列为 Conversion，如是根据§13.3.3.1.2/4 从TData<float[100][100]> 到float[100][100] 的用户定义的转换。从float [100][100]& 到float (*)[100] 的转换在表9 中被列为完全匹配。编译器不允许从这两个转换序列中进行选择。

Q1：并非所有编译器都以相同的方式遵守标准。发现在某些特定情况下编译器的执行方式与其他编译器不同，这是很常见的。在这种情况下，g++ 实现者决定抱怨标准不允许编译器选择，而英特尔实现者可能只是默默地应用了他们喜欢的转换。

Q2：当您更改用户定义的operator[] 的签名时，参数与传入的类型完全匹配。 t[1] 与 t.operator[](1) 完美匹配，没有任何转换，因此编译器必须遵循该路径。

Answer 3

我不知道确切的答案是什么，但是...

因为这个运算符：

operator ptr_t & () { return data; }

已经存在接受size_t 作为索引的内置[] 运算符（数组订阅）。所以我们有两个[] 运算符，内置的和你定义的。 Booth 接受size_t，因此这可能被视为非法超载。

//编辑
这应该可以按您的预期工作

template<typename ptr_t>
struct TData
{
    ptr_t data;
    operator ptr_t & () { return data; }
};

Answer 4

在我看来，

t[1][1] = 5;

编译器必须在两者之间做出选择。

value_type & operator [] ( size_t id ) { return data[id]; }

如果将int 文字转换为size_t，则匹配，或者

operator ptr_t & () { return data; }

后跟普通数组索引，在这种情况下索引的类型完全匹配。

---

至于错误，GCC 作为编译器扩展似乎想为您选择第一个重载，并且您正在使用 -pedantic 和/或 -Werror 标志进行编译，这迫使它遵守标准的字眼.

（我没有学究气，所以没有引用标准，特别是在这个话题上。）

Answer 5

我试图展示表达式 t[1][1] 的两个候选者。这些都是相等的 RANK (CONVERSION)。因此模棱两可

我认为这里的问题是根据 13.6/13 的内置 [] 运算符定义为

T& operator[](T*, ptrdiff_t);

在我的系统上，ptrdiff_t 被定义为“int”（这可以解释 x64 行为吗？）

template<typename ptr_t> 
struct TData 
{ 
    typedef typename boost::remove_extent<ptr_t>::type value_type; 
    ptr_t data; 

    value_type & operator [] ( size_t id ) { return data[id]; } 
    operator ptr_t & () { return data; } 
}; 

typedef float (&ATYPE) [100][100];

int main( int argc, char ** argv ) 
{ 
    TData<float[100][100]> t;    

    t[size_t(1)][size_t(1)] = 5; // note the cast. This works now. No ambiguity as operator[] is preferred over built-in operator

    t[1][1] = 5;                 // error, as per the logic given below for Candidate 1 and Candidate 2

    // Candidate 1 (CONVERSION rank)
    // User defined conversion from 'TData' to float array
    (t.operator[](1))[1] = 5;

    // Candidate 2 (CONVERSION rank)
    // User defined conversion from 'TData' to ATYPE
    (t.operator ATYPE())[1][1] = 6;

    return 0; 
}

编辑：

这是我的想法：

对于候选 1（运算符 []），转换序列 S1 是 用户定义的转换——标准转换（int to size_t）

对于候选2，转换序列S2为 用户定义的转换 -> int 到 ptrdiff_t（对于第一个参数）-> int 到 ptrdiff_t（对于第二个参数）

转换序列 S1 是 S2 的子集，应该更好。但这里有一个问题......

以下来自 Standard 的引用应该会有所帮助。

$13.3.3.2/3 个州 - 标准 转换序列 S1 更好 转换顺序比标准 转换序列 S2 if — S1 是 S2 的正确子序列（比较 中的转换序列 由 13.3.3.1.1 定义的规范形式， 不包括任何左值变换； 身份转换序列是 被认为是任何的子序列 非恒等式转换序列）或， 如果不是那样...

$13.3.3.2 states-" 用户定义 转换序列 U1 更好 转换序列比另一个 用户定义的转换序列 U2 if 它们包含相同的用户定义 转换函数或构造函数和 如果第二个标准转换 U1的序列优于 第二个标准转换序列 U2。”

这里的第一部分和条件“如果它们包含相同的用户定义的转换函数或构造函数”不成立。因此，即使 and 条件的第二部分“如果 U1 的第二个标准转换序列优于 U2 的第二个标准转换序列。”成立，S1 和 S2 都不是优先于其他。

这就是为什么 gcc 的 phantom 错误消息“ISO C++ 说这些是模棱两可的，即使第一个的最差转换优于第二个的最差转换”

这很好地解释了歧义，恕我直言

Answer 6

重载解决方案令人头疼。但是由于您偶然发现了一个对示例过于具体的修复（消除将索引操作数转换为operator[]）（文字是int 类型，但您将使用的大多数变量不是），也许您可​​以概括它：

template< typename IT>
typename boost::enable_if< typename boost::is_integral< IT >::type, value_type & >::type
operator [] ( IT id ) { return data[id]; }

很遗憾，我无法对此进行测试，因为 GCC 4.2.1 和 4.5 在 --pedantic 下毫无怨言地接受了您的示例。这确实引发了一个问题，它是否是编译器错误。

此外，一旦我消除了 Boost 依赖项，它就通过了 Comeau。