构造函数的显式性是否会因初始化形式被忽略？Clang与GCC编译分歧解析

这问题我之前也碰到过，确实挺挠头的——不同编译器对explicit构造函数在列表初始化场景下的重载决议处理居然不一样，很容易让人摸不着头脑。

先把问题的核心场景捋清楚，我猜你的代码大概是这样的：

struct A {
    A(int, int, int); // 最初的构造函数
    A(const A&);       // 拷贝构造函数
};

int main() {
    A a{1, 2, 3}; // 这里触发重载决议失败
}

为什么会失败？因为C++的列表初始化规则里，{1,2,3}有两条可行的初始化路径：

• 直接匹配A(int,int,int)构造函数，初始化对象a；
• 先隐式构造一个临时的A对象（用{1,2,3}匹配第一个构造函数），再通过拷贝构造函数初始化a。

这两条路径的优先级相同，所以编译器就报重载决议失败了。

你想到把第一个构造函数改成explicit A(int, int, int)，这个思路本身是对的——explicit会禁止隐式转换构造临时对象，照理说第二条路径应该被阻断，只剩第一条可行路径才对。那为什么GCC还是报错？

这其实是Clang和GCC在标准解读上的细微差异：

• Clang严格遵循标准：当构造函数被标记为explicit时，用{1,2,3}隐式构造临时A的行为是被禁止的，所以重载决议里只有explicit A(int,int,int)这一个候选，编译通过；
• 而GCC在某些旧版本中，会在重载决议的候选阶段先把拷贝构造函数算进来，之后才检查隐式转换是否合法。虽然最终这条路径应该被排除，但GCC的处理逻辑导致它在候选阶段就认为有两个可行构造函数，从而报错。

那怎么解决这个问题？给你几个靠谱的方案：

• 方案一：改用括号初始化
  把A a{1,2,3}改成A a(1,2,3)，这样就不会触发列表初始化的双路径检查，直接匹配A(int,int,int)构造函数，不管是Clang还是GCC都能正常编译；
• 方案二：明确禁用拷贝构造的这条路径（如果业务允许）
  如果你不需要拷贝构造函数，可以把它标记为delete：

  A(const A&) = delete;
  

  这样第二条路径直接被排除，不管用列表还是括号初始化都没问题；
• 方案三：升级GCC版本
  较新的GCC版本（比如GCC 10及以上）已经修复了这个解读差异，对explicit构造函数在列表初始化中的处理和Clang保持一致，不会再报这个错误。

总结一下，本质上是不同编译器对C++标准中“explicit构造函数与列表初始化隐式转换”的规则解读差异导致的，选上面的任意一个方案都能解决你的问题。

内容的提问来源于stack exchange，提问作者StoryTeller - Unslander Monica