为什么C++编译器对许多花括号有不同的处理方式？

Why are many curly brackets treated differently by C++ compilers?(为什么C++编译器对许多花括号有不同的处理方式？)

问题描述

在下面的C++20程序中，我错误地在B{{{{A{}}}}}中额外放了一对花括号{}：

#include <iostream>

struct A
{
    A() { std::cout << "A() "; }
    A( A&& ) = delete;
    ~A() { std::cout << "~A() "; }
};

struct B { std::initializer_list<A> l; };

int main()
{
    [[maybe_unused]] auto x = B{{{{A{}}}}};
    std::cout << ". ";
}

Clang拒绝了它，但出现了一个奇怪的错误：

错误：调用‘const A’的已删除构造函数

但令我惊讶的是GCC接受了(https://gcc.godbolt.org/z/aPWe13xfc)。

您能解释一下GCC为什么接受它(它如何处理多余的曲线花括号)？

推荐答案

B{…}，因为没有指定初始化器列表的单个元素，并且不是B类型(因为它根本没有类型)，所以是聚合初始化([dcl.init.list]/3.4)。B::l因此是从{{{A{}}}}复制初始化的；它是std::initializer_list的专门化，因此适用/3.6和/5。创建1const A"；数组，{{A{}}}是其单个元素的初始值设定项。

因此，我们可以将代码减少到

const A a = {{A{}}};

根本没有提到B，确实是郎平和GCC对这句话产生了同样的分歧。Clang拒绝它似乎是正确的：通过/3.7将初始化发送给构造函数，显然没有可行的构造函数(因此关于删除的Move构造函数是错误的)。

奇怪的是，在这里(或在原始文件中)删除多余的大括号会导致两个编译器都接受：

const A a = {A{}};

尽管A不是一个集合，因此/3.7仍然适用。想必两个编译器都过度地执行"；Guaraned Copy Elsion&Quot；(尽管程度不同)，使用最终将由其初始化的对象标识pr值A{}；然而，这只发生在[dcl.init.General]/16.6.1中，这在本分析中不起作用。

这篇关于为什么C++编译器对许多花括号有不同的处理方式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！