c++ - 检查引用元组是否默认可构造时出错

Question

使用 g++-5 我得到以下输出

#include <type_traits>
#include <tuple>
int main()
{
  bool b;
  b = std::is_default_constructible<int>::value; //Compiles, returns true
  b = std::is_default_constructible<int&>::value; //Compiles, returns false
  b = std::is_default_constructible< std::tuple<int> >::value; //Compiles, returns true
  b = std::is_default_constructible< std::tuple<int&> >::value; //Does not compile
}

这是 is_default_constructible 实现中的错误吗？

错误信息是一个很长的堆栈列表，结尾是:

/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/../../../../include/c++/5.1.0/tuple:105:9: error: reference to type 'int' requires an initializer
  : _M_head_impl() { }

Answer 1

这不是 is_default_constructible 中的错误.该类型特征只需要检查默认构造的直接上下文，它不必深入评估任何成员初始值设定项。这个限制可能是为了可以通过使用 SFINAE 在没有专用编译器魔法的情况下实现它。 (参见 [meta.unary.prop]，尤其是第 7 页)。

tuple和 pair如果元素类型不能默认构造，则默认构造函数不需要在直接上下文中失败(SFINAE 友好)。 LWG 2367 已解决此问题，它为 tuple 引入了以下 SFINAE 要求默认构造函数:

Remarks: This constructor shall not participate in overload resolution unless is_default_constructible<Ti>::value is true for all i. [...]

有了这个附加要求，元组的默认构造必须以 SFINAE 友好的方式失败，这样 is_default_constructible现在适用于 tuple如果元素无法在直接上下文中默认构造(引用类型就是这种情况)。

LWG 2367 目前处于就绪状态；提议的决议尚未(尚未)纳入 github 草案。

---

[-- 这部分还在考虑中

Yakk在评论中提出了一个重要的观点:为什么 is_default_constructible必须深度实例化成员初始值设定项？

据我所知，这与条件 constexpr 有关tuple 的活跃度的默认构造函数。 is_default_constructible导致默认构造函数的实例化。它只需要实例化声明，以确定是否可以在即时上下文 中无故障地调用此构造函数。但是，声明的实例化需要确定 constexpr 'iveness，这导致构造函数定义的实例化。

标记为constexpr的类模板的成员函数(或构造函数)只是有条件的 constexpr : 只有那些类模板实例化的成员函数才会是 constexpr body 不违反constexpr的地方限制。这需要构造函数主体的实例化，以便构造函数检查成员初始值设定项是否允许在 constexpr 中使用。功能。考虑:

struct nonconstexpr { nonconstexpr() { std::cout << "runtime\n"; } };
struct isconstexpr { constexpr isconstexpr() {} };

template<typename T>
struct wrapper { T t; constexpr wrapper() : t() {} };

在实例化 wrapper 的默认构造函数时, 编译器必须实例化成员初始值设定项以确定此实例化是否应为 constexpr .

在std::tuple的情况下，这会在某处导致成员初始化器的实例化，该成员初始化器试图对引用元组叶(数据成员)进行值初始化。这是一个错误，它不会在默认构造函数的原始实例化的直接上下文中发生。因此，这是一个硬错误，而不是直接上下文中的替换失败。

--]

这部分我不是很清楚因为CWG 1358基本上使所有实例化constexpr , 他们是否真的满足标准。事实上，gcc 6.0 不会编译以下示例，而 gcc 5.1 和 clang 3.7 会拒绝它:

#include <type_traits>

template<typename T>
struct foo
{
    T t;
    constexpr foo() {} // remove `constexpr` to make it compile everywhere
};

int main()
{
    static_assert(std::is_default_constructible<foo<int&>>{}, "!");
}

CWG 1358 还告诉我们为什么这两种方法(条件 constexpr 和 constexpr 尽管违反)之间的区别很重要:

Questions arose in the discussion of issue 1581 as to whether this approach — making the specialization of a constexpr function template or member function of a class template still constexpr but unable to be invoked in a constant context — is correct. The implication is that class types might be categorized as literal but not be able to be instantiated at compile time. This issue is therefore returned to "review" status to allow further consideration of this question.

---

对于 libc++，存在错误 #21157 ，已于 2014-10-15 解决并出现在 clang3.6 分支中。对于 libstdc++，似乎没有错误报告；该问题已在 combined commit on 2015-06-30 中修复它还实现了 N4387 - Improving Pair and Tuple (Revision 3)目前似乎没有出现在任何 gcc5 分支中。