[Из песочницы] Рефлексия в C++1408.12.2017 12:18

Здесь идет aggregate инициализация временной переменной, и мы передаем туда инстансы ubiq«а. В этот раз они держат указатель на выходной массив: здесь types это выходной массив, в который мы запишем идентификаторы типов полей. После этой строчки (после инициализации временной переменной) выходной массив types будет хранить в себе идентификаторы типа каждого поля. Функция type_to_array_of_type_ids является constexpr, т.е все можно использовать на этапе компиляции. Красотень! Нам осталось идентификаторы превратить обратно в типы. Делается это вот так:

template 
constexpr auto as_tuple_impl(std::index_sequence) noexcept {
    constexpr auto a = array_of_type_ids();              // #0

    return std::tuple<                                      // #3
        decltype(typeid_conversions::id_to_type(            // #2
            size_t_{}                                 // #1
        ))...                                               
    >{};
}

Нулевая строчка: здесь мы получаем массив идентификаторов. Здесь тип переменной a — это что-то похожее на std: array, но сильно дотюненный, чтобы им можно было пользоваться в constexpr выражениях (потому что у нас C++14, а не C++17, где большинство проблем с constexpr для std: arrary поправлено).

В строчке #1 мы создаем интегральную константу от элемента из массива. Интегральная константа — это std: integral_constant первый параметр для которой это size_t_, а вторым параметром будет как раз наша a[I]. size_t_ — это using декларация, алиас. В строчке #2 мы конвертируем идентификатор обратно к типу, а в строчке #3 мы создаем std: tuple, и каждый элемент из этого tuple«а точно соответствует типам данных внутри структуры T, структуры внутри которой мы заглядывали. Теперь мы можем сделать что-нибудь очень стрёмное. Например, reinterpret_cast пользовательской структуры к tuple«у. И мы можем работать с пользовательской структурой как с tuple«ом. Ну да стрёмненько: reinterpret_cast.

Предупреждаю, не пытайтесь скопировать и запустить потому, что код немного упрощен. Например у std: tuple«а не регламентирован порядок создания и уничтожения аргументов: некоторые имплементации инициализируют аргументы с конца вперед, хранят их не в том порядке, из-за чего std: tuple не работает. Надо сделать свой.

Поехали дальше. Что делать с указателями: указатели на константные указатели, на указатели на int«ы и т.п?

У нас имеется функция type_to_id. Она возвращает std: size_t и куча битиков из этого std: size_t у нас не использовано: мы использовали только под 32 фундаментальных типа. Так вот, эти битики можно использовать под кодирование информации об указателе. Например, если у нас в пользовательской структуре содержится поле с типом unsigned char, то в бинарном виде она будет выглядеть следующим образом:

unsigned char c0; // 0b00000000 00000000 00000000 00000001


Наименее значащий бит содержит идентификатор char«а. Это единичка: так мы его назначили в макросе. Если у нас указатель unsigned char, то наиболее значащие битики будут теперь хранить информацию о том, что это указатель:

unsigned char* с1; // 0b00100000 00000000 00000000 00000001


Если у нас указатель константный, то наиболее значащие битики хранят информацию о том, что это константный указатель:

const unsigned char* с2; // 0b01000000 00000000 00000000 00000001


Если мы добавляем дополнительный уровень индирекции (еще один указатель), то другие наиболее старшие битики поменяются и будут хранить информацию о том, что у нас указатель:

const unsigned char** с3; // 0b01000100 00000000 00000000 00000001


Меняем нижележащий тип: наиболее значащие биты не меняются, наименее значащие теперь содержат идентификатор семерку, что означает, что мы работаем с short«ом:

const short** s0; // 0b01000100 00000000 00000000 00000111


Добавляем функции, которые преобразовывают тип в идентификатор (и соответственно добавляют эти битики):

template
constexpr std::size_t type_to_id(identity)

template
constexpr std::size_t type_to_id(identity)

template
constexpr std::size_t type_to_id(identity)

template
constexpr std::size_t type_to_id(identity)

И добавляем обратные функции, которые идентификатор преобразовывают обратно к типу:

template constexpr auto id_to_type(size_t_,
if_extension = 0) noexcept;

template constexpr auto id_to_type(size_t_,
if_extension = 0) noexcept;

template constexpr auto id_to_type(size_t_,
if_extension = 0) noexcept;

template constexpr auto id_to_type(size_t_,
if_extension = 0) noexcept;

Здесь if_extension — это std: enable_if с алиасами и кучей магии. Магия заключается в том, что, в зависимости от идентификатора, она позволяют вызвать только одну из представленных функций.

Что делать с enum«ами я не знаю. Единственное, что я смог придумать — это вызывать std: underlying_type. То есть мы теряем информацию о том что это за enum: мы не можем зарегистрировать все пользовательские enum«ы в нашем списке фундаментальных типов, это просто невозможно. Вместо этого мы кодируем только то, как этот enum хранится. Eсли он int, то мы будем сохранять его как int, если пользователь указал class enum: char, то мы получим char и будем кодировать только char, информация о типе enum«а потеряется.

Со сложными структурами и классами та же проблема: мы не можем их все зарегистрировать нашем списке фундаментальных типов. Поэтому мы будем просто еще раз заглядывать внутрь класса и все поля, которые есть в этом классе кодировать так, как будто они находятся в нашем классе нулевого уровня.

Допустим у нас структура а, в ней имеется поле тип которого это структура b, мы заглянем внутрь b и все поля из b затащим внутрь a. Я упрощаю: там еще куча логики с alignment«ами чтобы не поломалось.

Делается это так: добавляется одна функция type_to_id:

template 
constexpr auto type_to_id(identity, typename std::enable_if<
    !std::is_enum::value && !std::is_empty::value>::type*) noexcept 
{
    return array_of_type_ids(); // Returns array!
}

В этот раз она может возвращать массив (все прошлые возвращали size_t). Нам надо будет поменять нашу структуру ubiq чтобы она могла работать с массивами, добавить логики на то, как определять offset«ы, куда нам писать offset«ы и информацию о том с какой подструктурой мы работаем. Это все долго и не очень интересно, есть пара примеров как это получается, это тоже технические детали.

Что это нам дает и где это все можно использовать? Нет, вам не надо писать это самому т.к есть готовая библиотека, которая все это реализует. Вот что это библиотека дает вам.

Во-первых сравнения: больше не надо самому вручную писать сравнения для
POD-структур. Там есть три метода. Т.е вы можете вообще ничего не писать, а подключить один заголовочный файл и для всех POD-структур у вас будут работать сравнение из коробки.

Есть гетерогенные сравнения: можно две структуры с одинаковыми полями, но
разными типами данных, сравнить друг с другом.

Есть универсальная функция хеширования: передаете туда любую пользовательскую структуру, и она считает от нее хэш.

Операторы ввода-вывода: то что мы уже увидели во введении, тоже всё есть и работает.

Когда я в первый раз рассказывал об этой метапрограммной магии, то очень обрадовались разработчики каких-то железяк (я точно не вспомню). Они говорят, что у них есть 1000 различных плоских структур, которые представляют собой различные протоколы. То есть структура один-в-один мапится на протокол. Для каждой из этих структур у них по три сериализатора (в зависимости от того на каком железе и какие там провода используются в дальнейшем). И того у них 3000 сериализаторов. Они были этим очень недовольны. С помощью этой библиотеке они смогли 3000 сериализаторов упростить до 3-х сериализаторов. Они были безумно рады.

Эти метапрограммные трюки открывают возможность для базовой рефлексии: можно написать новые type_traits, например: is_continuous_layout, is_padded, has_unique_object_representations (как в C++17).

Можно написать замечательные функции punch_hole (которых нету в библиотеки) и которые определяют в пользовательской структуре неиспользованные битики и байтики, возвращают ссылку на них, позволяя другим людям их использовать.

Наконец можно написать более обобщенные алгоритмы: например можно доработать boost: spirit, так, чтобы он сразу парсил в пользовательскую структуру, и чтобы не надо было эту структуру объявлять с помощью макросов из boost: fusion и boost: spirit. Кстати, один из разработчиков boost: spirit ко мне подошел и сказал:»- Это гениально! Я хочу эту штуку, дай мне ссылку на библиотеку». Я ему дал.

Пара примеров. Есть такая страшная структура:

namespace foo {
    struct comparable_struct {
        int i; short s; char data[50]; bool bl; int a,b,c,d,e,f;
    };
} // namespace foo

std::set s;

В ней куча полей. Проблема в том, что мы эту структуру хотим в какой-то контейнер передать. Например в std: set. Без библиотеки пришлось бы писать страшный компаратор для этой структуры. Можно было бы воспользоваться std: tie для того чтобы написать компаратор, но если структура поменяется, то надо помнить, что везде надо внести соответствующие изменения. Ад. Лучше об этом не задумываться. С библиотекой все работает из коробки: берете структуру, пихаете ее в std: set, все работает. Также работает сериализация этой структуры:

std::set s = { /* ... */ };
std::ofstream ofs("dump.txt");

for (auto& a: s)
    ofs << a << '\n';

Просто в ofstream гоните переменные ни о чем не думая.

Также работает десериализация: просто из потока гоните значения обратно в структуру, вставляете в контейнер, которым хотите пользоваться:

std::set s;
std::ifstream ifs("dump.txt");

foo::comparable_struct cs;
while (ifs >> cs) {
    char ignore = {};
    ifs >> ignore;
    s.insert(cs);
}

Красота: кода минимум.

Мой любимый пример потому, что он самый бессмысленный, но выглядит красиво. Функция flat_tie: она позволяет вам проинициализировать вашу структуру из std: tuple.

template 
auto flat_tie(T& val) noexcept;

struct my_struct { int i, short s; };
my_struct s;
flat_tie(s) = std::tuple{10, 11};

Теперь у вас my_struct: i хранит значение 10, а my_struct: s хранит 11 внутри структуры s.

Таким образом на этот момент у нас имеется библиотека, которая позволяет вам делать рефлексию, какую-никакую, но работающую в C++14, куча примеров того где это можно использовать.

Но в библиотеке используется reinterpret_cast. А reinterpret_cast«ы я не люблю: они не позволяют делать функции constexpr, да и некрасиво это.

Поэтому давайте попробуем это исправить. Исправим это быстренько и простенько: всего в полмегабайта кода уложимся. Делать мы это будем в C++17. Идея следующая: в C++17 добавили structure binding. Это такая вещь, которая позволяет нам структуру разложить на поля, получить ссылки на поля. Единственная проблема состоит в том, что нужно точно знать количество полей внутри структуры иначе все не соберется, и через enable_if невозможно использовать этот structure binding. Но мы же в начале статьи уже научились получать количество полей внутри структуры. Из количества полей делаем тип данных и используем tag dispatching:

template 
constexpr auto as_tuple(T& val) noexcept {
  typedef size_t_()> fields_count_tag;
  return detail::as_tuple_impl(val, fields_count_tag{});
}

Генерим кучу функций as_tuple_impl:

template 
constexpr auto as_tuple_impl(T&& val, size_t_<1>) noexcept {
  auto& [a] = std::forward(val);
  return detail::make_tuple_of_references(a);
}

template 
constexpr auto as_tuple_impl(T&& val, size_t_<2>) noexcept {
  auto& [a,b] = std::forward(val);
  return detail::make_tuple_of_references(a,b);
}

У этих функций as_tuple_impl вторым параметром будет идти количество полей внутри структуры T. Если мы определили, что внутри структуры T у нас одно поле, то вызовется первая функция as_tuple_impl. Она использует structure binding, достает первое поле, делает кортеж в котором будет ссылка на это поле, возвращает этот кортеж пользователю. Если у нас два поля внутри структуры, то вызываем structure binding для двух полей. Это уже вторая функция, она раскладывает пользовательскую структурно на поля, а и b, возвращаем кортеж, который хранит ссылки на первое поле и на второе поле. Красота!

Самое приятное, что все это constexpr, и теперь мы можем написать std: get который работает с пользовательскими полями и структурами — и все это на этапе компиляции. Красотень неимоверная. Единственная проблема это то, что код со structure binding еще не тестировался: компиляторы еще не поддерживают structure binding. Поэтому это красивая теория, и скорее всего с парой изменений она заработает.

Оригинальный доклад Антона antoshkka Полухина — https://youtu.be/jDI5CHKFKd0
Библиотека Precise and Flat Reflection (magic_get)

© Habrahabr.ru