Почему тип boost :: hana :: tuple_c определяется реализацией? - PullRequest
Новая
       32

Почему тип boost :: hana :: tuple_c определяется реализацией?

0 голосов
/ 30 апреля 2018

Документация Boost.Hana для tuple_c состояния:

Также обратите внимание, что тип объектов, возвращаемых 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 просто имеет: 

#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 не лишняя?

Ответы [ 3 ]

0 голосов
/ 30 апреля 2018

Не говоря с властью, но я бы сказал, что упаковка tuple_c с to_tuple на самом деле является излишней. В документации утверждается, что результат равен функционально эквивалентным - make_tuple, за исключением того, что тип не гарантированно будет одинаковым.

Одна из возможных оптимизаций будет возвращать что-то вроде этого: 

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

Чтобы быть уверенным, что я сделал запрос на выборку, чтобы посмотреть, сможем ли мы удалить лишнее преобразование из примера.

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

ОБНОВЛЕНИЕ : автор Boost.Hana подтвердил, что преобразование не нужно, и пример был обновлен, чтобы отразить это.

0 голосов
/ 01 мая 2018

На самом деле, документация содержит это в FAQ:

Зачем оставлять представление некоторого контейнера определенным реализацией?

Во-первых, это дает гораздо больше возможностей для реализации выполнять оптимизацию во время компиляции и во время выполнения с использованием умного представления для конкретных контейнеров. Например, кортеж содержащие однородные объекты типа T могут быть реализованы как вместо этого массив типа T, который более эффективен во время компиляции. Во-вторых, и самое главное, получается, что зная тип гетерогенный контейнер не так полезен, как вы думаете. В самом деле, в контексте гетерогенного программирования, тип объекта возвращаемое вычислением обычно тоже является частью вычисления. В Другими словами, нет способа узнать тип возвращаемого объекта. алгоритмом без фактического выполнения алгоритма.

0 голосов
/ 30 апреля 2018

Фраза «определена реализация» не описывает реализацию. В нем прямо говорится, что выбор реализации оставлен недокументированным специально по той или иной причине. Конечно это реализовано как-то . Пользователи не должны полагаться на какую-либо конкретную реализацию, а должны использовать только документированные API.

Оставить выбор реализации недокументированным - разумное значение по умолчанию, если только нет особой причины его документировать. Это верно, даже если есть только один очевидный выбор сегодня , потому что завтра все может измениться.

...