C++标准：std::vector<A>默认成员初始化是否允许A为不完全类型？

核心结论 #

根据C标准的演进和具体条款，该场景的合法性取决于**C版本和编译器对标准条款的实现细节**，具体如下：

• C++17：标准允许该写法，但编译器可选择是否延迟实例化vector的默认构造函数；Clang17的行为符合标准，GCC13的报错属于实现选择。
• C++20：标准收紧了相关要求，此时该写法属于非法，Clang17的报错符合标准。

详细解释 #

1. 不完全类型与std::vector的基础规则 #

从C++17开始，标准明确规定：如果使用的分配器满足「分配器完整性要求」（默认的std::allocator<A>满足此要求），则std::vector<T>支持不完全类型T的声明和部分操作。但有一个关键前提：当需要执行涉及元素构造、析构或内存分配的操作时，T必须是完整类型。

对于std::vector<A>的默认构造函数：它仅初始化vector的内部指针、大小和容量，不会构造任何元素，因此理论上不需要A是完整类型。

2. 默认成员初始化器的实例化时机差异 #

问题的核心在于：默认成员初始化器vec{}的存在，会在何时触发std::vector<A>默认构造函数的实例化？

• C++17标准：默认成员初始化器属于「潜在求值表达式」，仅当构造函数实际调用它时（即构造函数被定义或调用时），才会触发对应函数的实例化。因此如果B的构造函数仅声明未定义，编译器可以延迟实例化vector<A>的默认构造函数，直到A变为完整类型后再处理——这正是Clang17在C++17模式下的行为。
  GCC13的报错则是实现层面的选择：它在类B的定义点就尝试实例化vector<A>的默认构造函数，而其vector实现要求此时A必须完整，因此报错。这种行为并不违反标准，因为标准允许实现对不完全类型的支持做更严格的限制。

• C++20标准：标准对默认成员初始化器的实例化时机做了调整，要求在类成为完整类型时，默认成员初始化器中的表达式必须满足所有语义要求。此时std::vector<A>的默认构造函数会在B的定义点被实例化，而根据C20对vector的细化规则，此时A作为不完全类型不满足要求，因此该写法非法——Clang17在C20模式下的报错符合标准。

3. 为何未定义构造/析构仍要求完整类型？ #

即使B的构造、析构仅声明未定义，部分编译器仍报错的原因在于：

• 编译器可能在类定义阶段就需要确定vector<A>的大小、布局，或者提前检查某些语义规则，而这些操作可能依赖A的完整类型。
• 对于析构函数：std::vector<A>的析构函数需要销毁所有元素，因此当B的析构函数被实例化时，A必须是完整类型。如果编译器在类定义点就预检查析构相关的依赖，也会触发报错。

4. 代码示例的特殊情况说明 #

当取消注释struct A {};后，GCC13恢复正常，但Clang17仍报错：这是因为A的定义在B的声明之后，B的析构函数~B()的实例化时机可能早于A变为完整类型的时机。此时需要确保B的构造、析构函数的定义在A的定义之后，才能让Clang正常编译。

解决建议 #

如果需要保留-Weffc++警告的同时使用不完全类型，可以采取以下方案：

• 将B的构造函数定义放在A的完整类型定义之后，并在构造函数初始化列表中显式初始化vec，避免使用默认成员初始化器。
• 升级到C++20后，必须确保A在B的定义前就成为完整类型，才能使用默认成员初始化器。

内容的提问来源于stack exchange，提问作者Dan Stahlke