Clang 或 GCC 拒绝/接受此 CTAD 代码是否正确?

问题描述

Clang 和 GCC disagree 接受此代码。

标准要求的行为是什么?

#include <utility>
#include <iostream>
#include <vector>

int main()
{
    std::vector pairs = {std::pair{1,11},{2,22},{3,33}};
    for (const auto& p: pairs) {
        std::cout << p.second << std::endl;
    }
}

注意:我知道这是 C++,所以标准可能是模糊的,但我认为一种行为是正确的。

解决方法

CTAD 的过程主要由 [over.match.class.deduct] 定义。从广义上讲,重载集是该类型的所有可访问构造函数,以及任何推导指南。并根据此规则解决重载集:

初始化和重载解析按照 [dcl.init] 和 [over.match.ctor]、[over.match.copy] 或 [over.match.list] 中的描述执行(根据初始化类型执行)

由于“执行的初始化类型”肯定是列表初始化,我们继续[over.match.list]。我们从哪里得到这个臭名昭著的项目符号列表:

  • 最初,候选函数是类 T 的初始化列表构造函数 ([dcl.init.list]),参数列表由初始化列表作为单个参数组成。

  • 如果没有找到可行的初始化列表构造函数,则再次执行重载解析,其中候选函数是类 T 的所有构造函数,参数列表由初始化列表的元素组成。

这告诉我们,initializer-list constructors 是优先的;他们首先以一种非常具体的方式(即构建一个 std::initializer_list 并将其作为参数传递)来解决重载决议。然而,Clang 给出了一个明显的错误:

note: candidate function template not viable: requires at most 2 arguments,but 3 were provided
     vector(initializer_list<value_type> __l,

也就是说,它试图调用构造函数,就好像“参数列表由初始化列表的元素组成”一样。这表明 Clang 在通过 CTAD 进行列表初始化时跳过了第一个要点。在括号初始化列表周围添加括号“修复”了该问题的事实也表明这就是正在发生的事情。

奇怪的是,它适用于简单的类型,比如整数的初始化列表。如果您将每个成员明确命名为 pair,它就会起作用。 Clang 可以auto-推断出 initializer_list 产生的 {std::pair{1,11},{2,22},{3,33}} 的类型就好了。所以这个错误看起来确实特定。

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...