Question

tuple_c州的Boost.Hana documentation：

另请注意tuple_c返回的对象类型和对make<tuple_tag>的等效调用可能会有所不同。

接下来是以下代码段：

BOOST_HANA_CONSTANT_CHECK(
    hana::to_tuple(hana::tuple_c<int, 0, 1, 2>)
        ==
    hana::make_tuple(hana::int_c<0>, hana::int_c<1>, hana::int_c<2>)
);

但是，tuple_c的{{3}}只有：

#ifdef BOOST_HANA_DOXYGEN_INVOKED
    template <typename T, T ...v>
    constexpr implementation_defined tuple_c{};
#else
    template <typename T, T ...v>
    constexpr hana::tuple<hana::integral_constant<T, v>...> tuple_c{};
#endif

并且，实际上，代码段在没有to_tuple包装器的情况下工作正常：

BOOST_HANA_CONSTANT_CHECK(
    hana::tuple_c<int, 0, 1, 2>
        ==
    hana::make_tuple(hana::int_c<0>, hana::int_c<1>, hana::int_c<2>)
);

问题：为什么定义tuple_c实施的实际类型？ to_tuple包装器是不是多余的？

Answer 1

短语＆＃34;实施定义＆＃34;没有描述实现。它明确指出，由于某种原因，实现选择是故意无意的。当然它是以某种方式实现。用户不应该依赖任何特定的实现，而只使用文档化的API。

留下未记录的实施选择是明智的默认，除非有特定的理由记录它。即使今天只有一个明显的选择，也是如此，因为明天事情可能会发生变化。

Answer 2

没有权威说话，但我会说用tuple_c包裹to_tuple实际上是多余的。文档说明结果<{>>功能上等同于到make_tuple，但不保证类型相同。

一种可能的优化方式是返回如下内容：

template <auto ...i>
struct tuple_c_t { };

为了确保我提出拉取请求，看看我们是否可以从示例中删除多余的转换。

https://github.com/boostorg/hana/pull/394

更新：Boost.Hana的作者确认转换是不必要的，并且示例已更新以反映出来。

Answer 3

实际上，常见问题解答中的文档has this covered：

为什么要保留一些容器的表示实现定义？

首先，它为实现提供了更多的摆动空间   使用聪明的方法执行编译时和运行时优化   特定容器的表示。例如，一个元组   包含类型T的同类对象可以实现为   而不是类型T的数组，这在编译时更有效。   其次，最重要的是，事实证明知道的类型   异构容器没有您想象的那么有用。确实，   在异构编程的上下文中，对象的类型   通过计算返回通常也是计算的一部分。在   换句话说，没有办法知道返回的对象的类型   通过算法而不实际执行算法。

为什么boost :: hana :: tuple_c实现定义的类型？

3 个答案: