为什么我的课程不可默认构造？

Question

我有这些课程：

#include <type_traits>

template <typename T>
class A {
public:
    static_assert(std::is_default_constructible_v<T>);

};

struct B {
   struct C {
      int i = 0;
   };

    A<C> a_m;
};

int main() {
    A<B::C> a;
}

编译时，a_m 不是默认可构造的，但a 是。

将C 更改为：

struct C {
      int i;
   };

一切都很好。

使用 Clang 9.0.0 测试。

Answer 1

标准文本和 cmets 中指出的几个主要实现都不允许这样做，但出于完全不相关的原因。

首先，“按部就班”的原因：A<C> 的实例化点按照标准是immediately before the definition of B，而std::is_default_constructible<C> 的实例化点就在其之前：

对于类模板特化，[...] 如果特化是 隐式实例化，因为它是从另一个内部引用的 模板特化，如果特化来自的上下文 被引用取决于模板参数，如果 特化没有在实例化之前实例化 封闭模板，实例化点是立即 在封闭模板的实例化点之前。 否则，这种特化的实例化点 紧接在命名空间范围声明或定义之前 那是指专业化。

由于此时C 显然不完整，因此实例化std::is_default_constructible<C> 的行为是未定义的。但是，请参阅 core issue 287，这将更改此规则。

---

实际上，这与 NSDMI 有关。

• NSDMI 很奇怪，因为它们会延迟解析 - 或者用标准术语来说，它们是“完整类上下文”。
• 因此，= 0 原则上可以引用 B 中尚未声明的内容，因此实现无法真正尝试解析它，直到它完成 B。
• 完成一个类需要隐式声明特殊成员函数，尤其是默认构造函数，因为C 没有声明构造函数。
• 该声明的部分内容（constexpr-ness、noexcept-ness）取决于 NSDMI 的属性。
• 因此，如果编译器无法解析 NSDMI，则无法完成该类。
• 结果，在实例化A<C>的那一刻，它认为C是不完整的。

处理延迟解析区域的整个领域都被严重低估，伴随着实现分歧。可能需要一段时间才能清理干净。

Answer 2

Undefined behavior是：

如果上面的模板的实例依赖，直接或 间接地，在不完整的类型上，并且实例化可能会产生 如果假设完成了该类型，则会出现不同的结果， 行为未定义。