将“unsigned char”传递给期望 char 或 const char* 的重载函数会导致歧义答案

【问题标题】：Passing an "unsigned char" to an overloaded function expecting either char or const char* results in ambiguity将“unsigned char”传递给期望 char 或 const char* 的重载函数会导致歧义
【发布时间】：2012-08-28 18:16:51
【问题描述】：

我使用QByteArray 来存储原始二进制数据。我使用QByteArray的追加函数来存储数据。

我喜欢使用无符号字符来表示字节，因为我认为 255 比 -1 更容易解释。但是，当我尝试将零值字节附加到 QByteArray 时，如下所示：

command.append( (unsigned char) 0x00));

编译器向call of overloaded append(unsigned char) is ambiguous 抱怨。据我了解，这是因为零可以解释为空指针，但是为什么编译器不将 unsigned char 视为 char，而不是想知道它是否是 const char*？当然，如果编译器在没有任何强制转换的情况下抱怨 command.append(0)，我会理解。

【问题讨论】：

(char) 和 (const char *) 是 command.append 的唯一重载吗？
如果您传递的是文字 0（否则无法转换为 const char*），为什么不将其转换为适当的类型？
@peachykeen：还有更多的重载，特别是 (const QByteArray&) 和 (const QString&)。
@DavidRodríguez-dribeas：我会的，但我想知道为什么它是必要的。

标签： c++ qt

【解决方案1】：

两个重载都需要类型转换 - 一个从 unsigned char 到 char，另一个从 unsigned char 到 const char *。编译器不会尝试判断哪个更好，它只是告诉您使其明确。如果一个是完全匹配的，它将被使用：

command.append( (char) 0x00));

【讨论】：

我明白了，所以 unsigned 关键字创建了一个新类型 unsigned char，它与 char 和 const char* 一样不同？
@SharpHawk：非正式地说，unsigned char 与char 的区别小于，而不是const char *。但是，在这种特定情况下（常量0），该语言认为这两个差异是等效的。

【解决方案2】：

unsigned char 和 char 是两种不同但可转换的类型。 unsigned char 和 const char * 也是两种不同的类型，在这种特定情况下也可以转换。这意味着您的重载函数都不是与参数完全匹配的，但在这两种情况下，参数都可以转换为参数类型。从语言的角度来看，这两个函数都同样适合调用。因此模棱两可。

您似乎认为unsigned char 版本应该被认为是“更好”的匹配。但是语言不同意你。

确实，在这种情况下，歧义源于(unsigned char) 0x00 是一个有效的空指针常量这一事实。你可以通过引入一个中间变量来解决这个问题

unsigned char c = 0x0;
command.append(c);

c 不符合空指针常量的条件，从而消除了歧义。尽管正如@David Rodríguez - dribeas 在 cmets 中指出的那样，您可以通过简单地将零转换为 char 而不是 unsigned char 来消除歧义。

【讨论】：