Рефлексия в C++Next на практике

Определение понятия "рефлексия" из Википедии:

In computer science, reflective programming or reflection is the ability of a process to examine, introspect, and modify its own structure and behavior.

В последние годы разрабатываются варианты ввода рефлексии в стандарт C++.

В этой статье мы напишем код на C++ с рефлексией для решения разных задач, скомпилируем и запустим его на форке компилятора с рабочей реализацией рефлексии.

Рефлексия в других языках

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

В языке Python в run-time можно получить класс объекта; имя класса; все его методы и аттрибуты; добавить методы и аттрибуты в класс; и так далее. По большому счету, каждый объект и класс это dict (с синтаксическим сахаром), который можно изменять как угодно.

В языке Java в run-time также можно получить класс объекта; его поля, методы, константы, конструкторы, суперклассы; получать и устанавливать значение поля по его имени; вызывать метод объекта по имени; и так далее. Информация о классах находится в памяти Java Virtual Machine.

Действия, описанные выше - как раз то, что обычно подразумевается под словом "рефлексия".

Эрзац-рефлексия в C++

В C++ постепенно добавлялись некоторые магические кусочки "языкознания", с помощью которых можно получить часть информацию о коде - например std::is_enum (compile-time), typeid (run-time).

Это можно отнести к рефлексии, но функционал спартанский и для великих свершений не годен. История знает разного рода приспособления для уменьшения боли.

Кодогенерация по описанию типа данных

К этому типу принадлежит protobuf - модный "носитель" данных.

В .proto-файле описывается структура данных (message Person), по которой кодогенератор для C++ может создать соответствующий ей класс (class Person) с геттерами/сеттерами, и возможностью сериализовать эти данные без копипаста имени каждого метода.

Сериализовать объект класса можно в бинарное представление (оптимальный путь, для передачи по сети), или в человекочитаемое представление (например для логирования).

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

Адские макросы и шаблоны

К этому типу принадлежит библиотека Boost.Hana. Для нее нужно описывать структуру нужным образом:

struct Person {
  BOOST_HANA_DEFINE_STRUCT(Person,
    (std::string, name),
    (int, age)
  );
};

Макрос "раскроется" и все сгенерирует. Похоже на "демосцену" - выжимают максимум возможностей из инструмента, который не был для этого предназначен.

Экстремальный залаз в компилятор

Интересные вещи можно сделать, проанализировав исходный код.

Некоторые инструменты (кодогенераторы/чекеры/etc.) создаются как "плагин" к используемому компилятору. Например, чтобы работать с исходниками на уровне AST (абстрактного синтаксического дерева), можно использовать cppast.

AST это промежуточный вариант между исходным кодом и ассемблером. К нему надо привыкнуть, но это проще, чем писать самодельный парсер кода на C++. Если кто-то смотрел исходники GCC или Clang, тот знает, что с нуля написать парсер малореально.

Особенности рефлексии в C++

В отличие от многих других языков, где с рефлексией работают в run-time, дух C++ требует сделать рефлексию в compile-time.

Так как язык старается соответствовать принципу "don’t pay for what you don’t use", то ~95% всей информации из исходников в рантайме просто испаряется. В языке не существует теоретической возможности сделать рефлексию в рантайме без раздувания бинаря чем-нибудь навроде RTTI (с многократно большим объемом).

C++ можно рассматривать как сборник из "под-языков", работающих на разных "уровнях". Условное деление:

• Собственно C++: работа с памятью, объектами, потоками (и вообще с интерфейсом ОС), манипуляция данными. Работает в run-time.

• Шаблоны: обобщенное программирование в исходниках. Работает (вычисляется) в compile-time.

• Constexpr-вычисления: это "интерпретируемое" подмножество "Собственно C++", от года в год расширяется. Подробнее о них можно прочитать в моей прошлой статье. Вычисляется в compile-time прямо внутри компилятора.

• Препроцессор: работает с токенами (отдельными словами) исходников. С C++ имеет очень посредственную связь, абсолютно такой же препроцессор могли бы сделать для Rust/Java/C#/etc. Единственный из "под-языков" не тьюринг-полный. Работает в compile-time.

Делать рефлексию в виде препроцессорных директив бессмыслено из-за отсутствия тьюринг-полноты. Остаются только шаблоны или constexpr-вычисления.

Сначала рефлексию планировали ввести в шаблонной парадигме, сейчас планируют ввести в constexpr-парадигме (так как возможности constexpr значительно расширились).

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

Рефлексия на шаблонах

Основной источник информации про рефлексию на шаблонах - pdf-ка Reflection TS, более короткое объяснение есть на cppreference.com.

Свой код с использованием рефлексии можно скомпилировать на godbolt.org, выбрав компилятор x86-64 clang (reflection).

Вводится оператор reflexpr(X), которому можно "скормить" вместо X что угодно: тип, выражение, имя переменной, вызов метода, и т.д.

Этот оператор вернет так называемый meta-object type (далее - магический тип"), который для нас будет являться безымянным incomplete классом. Пример кода:

enum Color {
    Red, Green, Blue
};

using MetaT = reflexpr(Color);

Этот класс будет удовлетворять некоторому множеству концептов (в Reflection TS есть таблица концептов).

Например, MetaT удовлетворяет концепту reflect::Enum, и не удовлетворяет reflect::Variable - ссылка на код с проверкой.

Работа происходит с помощью "трансформаций" одних магических типов в других. Список доступных трансформаций зависит от того, каким концептам удовлетворяет исходный тип. Например, Reflection TS определяет такой шаблон, доступный только удовлетворяющим reflect::Enum магическим типам:

template <Enum T> struct get_enumerators;

// и его short-hand
template <Enum T>
using get_enumerators_t = typename get_enumerators<T>::type;

Таким образом, трансформация get_enumerators_t<MetaT> скомпилируется. С ее помощью мы получим другой магический тип, на этот раз удовлетворяющий концепту reflect::ObjectSequence.

Выведем название первого элемента enum Color спустя несколько трансформаций:

int main() {
    constexpr std::string_view name = get_name_v<get_element_t<0, get_enumerators_t<MetaT>>>;
    std::cout << "The name of the first value is "" << name << """ << std::endl;
}

Ссылка на код.

Основная претензия к шаблонному подходу - неочевидность, как надо писать код. Мы хотим написать цикл по ObjectSequence? Обычным for-ом это сделать нельзя, есть только размер последовательности и получение элемента из него, и некий unpack_sequence:

template <ObjectSequence T> struct get_size;
template <size_t I, ObjectSequence T> struct get_element;
template <template <class...> class Tpl, ObjectSequence T>
  struct unpack_sequence;

Если мы хотим сделать такую элементарную задачу, как по значению enum-а получить его строковое представление, надо написать какую-то жуть, в которой совсем ничего не понятно - ссылка на код в gist.

Рефлексия в constexpr

Язык развивают живые люди, у них тоже идет кровь из глаз при виде метапрограммирования на шаблонах, поэтому сейчас развивается другой подход к рефлексии.

Основные источники информации про текущий вариант рефлексии - документ P2320, видео-выступление Andrew Sutton на ютубе, и частично Wiki в гитхабе реализации.

Рефлексия вводится в виде оператора ^X перед рефлексируемой сущностью X. Применение оператора создаст constexpr-объект типа std::experimental::meta::info.

После манипуляций с объектом (которые должны происходить в compile-time) можно "вернуть" его в "реальный" мир через оператор [:X:] (называется "splice"). Запись [:^X:] практически эквивалентна X.

Andrew Sutton в видео приводит игрушечный пример с созданием объекта типа T****...* (количество звёздочек равно N). Вот так можно сделать через шаблоны:

template<typename T, int N>
auto make_indirect_template() {
    if constexpr (N == 0) {
        return T{};
    } else {
        return make_indirect_template<T*, N - 1>();
    }
}

А вот так можно сделать через рефлексию:

consteval meta::info make_pointer(meta::info type, int n) {
    for (int i = 0; i < n; ++i) {
        type = meta::add_pointer(type);
    }
    return type;
}

template<typename T, int N>
auto make_indirect_reflective() {
    return typename [:make_pointer(^T, N):]{};
}

Код внутри consteval-методов выполняется только в compile-time. Все consteval-методы после компиляции "испаряются", то есть их код в бинарнике отсутствует.

Можно вывести имя получившихся типов:

int main() {
    auto ptr1 = make_indirect_template<int, 42>();
    std::cout << meta::name_of(meta::type_of(^ptr1)) << std::endl;

    auto ptr2 = make_indirect_reflective<int, 42>();
    std::cout << meta::name_of(meta::type_of(^ptr2)) << std::endl;
}

Компиляция на godbolt

Соглашение о записи операторов

Записи операторов ^X и [:X:] могут не пройти проверку временем и видоизмениться к момента входа в стандарт. Но это будут взаимозаменяющие записи.

Ранее вместо ^X был reflexpr(X), вместо [:X:] был unreflexpr(X).

На данный момент текущая запись является "официальной", что можно увидеть в github-тикете про P2320.

Компиляция и запуск

Свой код с использованием рефлексии можно запустить на cppx.godbolt.com, выбрав компилятор p2320 trunk.

Это не очень удобно и быстро, поэтому я компилирую через терминал. В лучших традициях форк компилятора предлагается собрать самому по инструкции, поэтому я создал docker-образ.

docker pull sehnsucht88/clang-p2320

docker run --rm -v /home/username/cpp:/cpp sehnsucht88/clang-p2320 -std=c++2a -freflection -stdlib=libc++ /cpp/code.cpp -o /cpp/bin

Рефлексия на практике

Теперь попробуем написать что-то рефлексивное.

Значение enum-а в строковом представлении

В отличие от "рефлексии на шаблонах", в "рефлексии на constexpr" это сделать намного проще. Пример кода (немного изменил код из видео Andrew Sutton):

template<typename T>
requires std::is_enum_v<T>
constexpr std::string_view to_string(T value) {
    template for (constexpr meta::info e : meta::members_of(^T)) {
        if ([:e:] == value) {
            return meta::name_of(e);
        }
    }
    throw std::runtime_error("Unknown enum value");
}

template for - это фича, которая не успела войти в стандарт C++20. В нашем случае она раскрывает range методом копипаста. Пусть у нас такой enum:

enum LightColor { Red, Green, Blue };

Тогда метод раскроется в такой вид:

template<>
constexpr std::string_view to_string<LightColor>(T value) {
    { if (Red == value) return "Red"; }
    { if (Green == value) return "Green"; }
    { if (Blue == value) return "Blue"; }
    throw std::runtime_error("Unknown enum value");
}

Аналогично можно сделать метод, который по строковому представлению вернет значение enum-а

template<typename T>
requires std::is_enum_v<T>
constexpr std::optional<T> from_string(std::string_view value) {
    template for (constexpr meta::info e : meta::members_of(^T)) {
        if (meta::name_of(e) == value) {
            return [:e:];
        }
    }
    return {};
}

Компиляция на godbolt

Проверка функций на internal linkage

Можно реализовать проверку на отсутствие видимых "снаружи" (вне единицы трансляции) методов с помощью вызова meta::is_externally_linked.

Небольшое отступление - в форке компиляции доступно несколько вспомогательных методов, работающих в compile-time:

• __reflect_dump - принимает meta::info, выведет в терминал AST соответствующей ему сущности.

• __compiler_error - принимает строку, завершает компиляцию ошибкой с выводом данной строки.

• __concatenate - соединяет несколько строковых литералов в один.

Первые два метода нужны для удобства разработки compile-time кода. Третий метод нужен, потому что std::string в compile-time пока еще нет в стандарте (но когда-то будет).

Про meta::info есть один факт - в некоторых случаях мы не можем написать метод так:

consteval void foo(meta::info r) { /* ... */ }

потому что компилятор думает, что meta::info протекает в run-time... Зато можем написать так:

template<meta::info R>
consteval void foo() { /* ... */ }

Теперь попробуем решить нашу задачу. Методы находятся внутри namespace. Поэтому надо проитерироваться по всем членам namespace, являющимися функциями. Также могут быть вложенные namespace, поэтому их также надо проверить рекурсивно.

template<meta::info R>
consteval void check_functions_linkage() {
    static_assert(meta::is_namespace(R));

    template for (constexpr meta::info e : meta::members_of(R)) {
        if constexpr (meta::is_function(e)) {
            __reflect_dump(e);
            if constexpr (meta::is_externally_linked(e)) {
                constexpr auto error_msg =
                    __concatenate("The method '", meta::name_of(e), "' is externally linked");
                __compiler_error(error_msg);
            }
        }

        if constexpr (meta::is_namespace(e)) {
            check_functions_linkage<e>();
        }
    }
}

Заведем игрушечный namespace - компиляция будет падать так, как нам нужно:

namespace outer {
    bool foo(int i) { return i == 13; }
    std::string bar(std::string s) { return s + s; };

    namespace inner {
        double fizz() { return 3.14; }
    } // namespace inner
} // namespace outer

int main() {
    check_functions_linkage<^outer>();
    std::cout << "compiled!" << std::endl;
}

Чтобы компиляция перестала падать, нужно сделать методы имеющими internal linkage.

namespace outer {
    static bool foo(int i) { return i == 13; }
    static std::string bar(std::string s) { return s + s; };

    namespace inner {
        static double fizz() { return 3.14; }
    } // namespace inner
} // namespace outer

namespace outer {
namespace {
    bool foo(int i) { return i == 13; }
    std::string bar(std::string s) { return s + s; };

    namespace inner {
        double fizz() { return 3.14; }
    } // namespace inner
} // anonymous namespace
} // namespace outer

При желании можно пропарсить всё, до чего только можно дотянуться - если итерироваться по глобальному namespace (он же ::). Рефлексия глобального namespace это ^::.

Компиляция на godbolt

Проверка, что тип является интерфейсом

Можно проверить, что тип является "абстрактным", то есть имеет хотя бы один чисто виртуальный метод, через std::is_abstract.

Понятие "интерфейс" в стандарте не зафиксировано, но можно выработать для него требования:

1. Все user-defined методы (т.е. которые юзер написал сам, а не которые сгенерированы компилятором) публичные и чисто виртуальные.

2. У класса нет переменных.

3. В классе есть публичный виртуальный деструктор, являющийся defaulted.

Вот как можно описать эти требования:

namespace traits {

template<typename T>
consteval bool is_interface_impl() {
    constexpr meta::info refl = ^T;
    if constexpr (meta::is_class(refl)) {
        template for (constexpr meta::info e : meta::members_of(refl)) {
            // interfaces SHALL NOT have data members
            if constexpr (meta::is_data_member(e)) {
                return false;
            }
            // every user function in interfaces SHOULD BE public and pure virtual
            if constexpr (meta::is_function(e) && !meta::is_special_member_function(e)) {
                if constexpr (!meta::is_public(e) || !meta::is_pure_virtual(e)) {
                    return false;
                }
            }
            // the destructor SHOULD BE virtual and defaulted
            if constexpr (meta::is_function(e) && meta::is_destructor(e)) {
                if constexpr (!meta::is_public(e) || !meta::is_defaulted(e) || !meta::is_virtual(e)) {
                    return false;
                }
            }
        }
        return true;
    }
    return false;
}

template<typename T>
constexpr bool is_interface = is_interface_impl<T>();

} // namespace traits

Можно протестировать написанный метод:

// IS NOT abstract, IS NOT interface
class foo {
public:
    void foo_void();
private:
    int _foo_int;
};
static_assert(not std::is_abstract_v<foo>);
static_assert(not traits::is_interface<foo>);

// IS abstract, IS NOT interface
class bar {
public:
    virtual void bar_void() = 0;
    std::string bar_string();
private:
    int _foo_int;
};
static_assert(    std::is_abstract_v<bar>);
static_assert(not traits::is_interface<foo>);

// IS abstract, IS NOT interface
class fizz {
public:
    virtual void fizz_void() = 0;
    std::string fizz_string();
};
static_assert(    std::is_abstract_v<fizz>);
static_assert(not traits::is_interface<fizz>);

// IS abstract, IS NOT interface
class buzz {
public:
    virtual void buzz_void() = 0;
    virtual std::string buzz_string() = 0;
};
static_assert(    std::is_abstract_v<buzz>);
static_assert(not traits::is_interface<buzz>);

// IS abstract, IS NOT interface
class biba {
public:
    virtual ~biba() { /* ... not defaulted dtor ... */ };
    virtual void biba_void() = 0;
    virtual std::string biba_string() = 0;
};
static_assert(    std::is_abstract_v<biba>);
static_assert(not traits::is_interface<biba>);

// IS abstract, IS interface
class boba {
public:
    virtual ~boba() = default;
    virtual void boba_void() = 0;
    virtual std::string boba_string() = 0;
};
static_assert(    std::is_abstract_v<boba>);
static_assert(    traits::is_interface<boba>);

Компиляция на godbolt

Сериализация объекта в JSON

Сериализация в JSON это такой FizzBuzz для любителей рефлексии. Каждый уважающий себя разработчик рефлексии рано или поздно это напишет.

В своем видео Andrew Sutton разбирает вопрос с JSON, но больше как псевдокод. Мы напишем свою реализацию.

Если модель данных немаленькая, то с "голым" JSON работать становится очень неудобно - всё нетипизированно и как будто постоянно лезешь в свалку данных, чтобы получить нужные поля. Можно конвертировать JSON в свои структуры, но это влечет кучу копипаста - чего можно избежать при наличии рефлексии.

Базовые типы JSON это Number, String, Boolean, Array, Object; пустое значение - null. Напишем концепты для каждого типа.

Number это каждый тип, удовлетворяющий std::is_arithmetic:

template<typename T>
concept JsonNumber = std::is_arithmetic_v<T>;

String это строковой тип, причем объект должен владеть строкой, а не просто знать о ней (как std::string_view). Потому что где сериализация - там и десериализация, поэтому нужен владеющий тип. Это, конечно, только std::string:

template<typename T>
concept JsonString = std::same_as<std::string, T>;

Boolean это просто bool:

template<typename T>
concept JsonBoolean = std::same_as<bool, T>;

Array должен быть контейнером из последовательных элементов. Другими словами, это должен быть SequenceContainer - std::array/std::vector/std::deque/std::forward_list/std::list.

К сожалению, готового концепта для них нет - есть только вилами по воде писанные свойства. Поэтому напишем свой концепт с нуля, который определяет, что тип является инстанциацией нужного шаблона:

static constexpr meta::info vector_refl = ^std::vector;
static constexpr meta::info array_refl = ^std::array;
static constexpr meta::info deque_refl = ^std::deque;
static constexpr meta::info list_refl = ^std::list;
static constexpr meta::info forward_list_refl = ^std::forward_list;

template<typename T>
consteval bool is_json_array_impl() {
    if constexpr (meta::is_specialization(^T)) {
        constexpr auto tmpl = meta::template_of(^T);
        constexpr bool result =
            tmpl == vector_refl || tmpl == array_refl ||
            tmpl == deque_refl || tmpl == list_refl ||
            tmpl == forward_list_refl;
        return result;
    }
    return false;
}

template<typename T>
concept JsonArray = is_json_array_impl<T>();

Object это просто класс/структура. В нем, конечно, должны быть дополнительные ограничения, чтобы сериализовать/десериализовать можно было достаточно простой тип - скажем, без членов со ссылочными типами. Но пока обойдемся базовым примером.

template<typename T>
concept JsonObject = std::is_class_v<T>;

Значение null можно ввести для std::optional, который не содержит значения.

static constexpr meta::info optional_refl = ^std::optional;

template<typename T>
consteval bool is_json_nullable_impl() {
    if constexpr (meta::is_specialization(^T)) {
        return meta::template_of(^T) == optional_refl;
    }
    return false;
}

template<typename T>
concept JsonNullable = is_json_nullable_impl<T>();

Теперь можно сериализовать объект в зависимости от того, какому концепту он удовлетворяет.

    template<Concept1 T>
    void write(T const& t) { /* ... */ }

    template<Concept2 T>
    void write(T const& t) { /* ... */ }

    template<Concept3 T>
    void write(T const& t) { /* ... */ }

    template<typename T>
    void write(T const& t) {
        if constexpr (Concept1<T>) {
            write_concept1(t);
        } else if constexpr (Concept2<T>) {
            write_concept2(t);
        } else if constexpr (Concept3<T>) {
            write_concept3(t);
        }
    }

Сделаем класс json_writer, пусть он принимает объект, куда можно стримить выходной поток

template<typename Out>
class json_writer {
public:
    json_writer(Out& out)
        : _out{out}
    {}
    
    // ... другой код ...

private:
    Out& _out;
};

Реализуем метод для сериализации, который будет "диспетчером" для разных JSON-типов:

    template<typename T>
    void write(T const& t) {
        if constexpr (JsonNullable<T>) {
            write_nullable(t);
        } else if constexpr (JsonNumber<T>) {
            write_number(t);
        } else if constexpr (JsonString<T>) {
            write_string(t);
        } else if constexpr (JsonBoolean<T>) {
            write_boolean(t);
        } else if constexpr (JsonArray<T>) {
            write_array(t);
        } else if constexpr (JsonObject<T>) {
            write_object(t);
        }
    }

Методы, которые вызываются из write, могут естественным образом делать рекурсивный запрос в write снова. Реализуем запись nullable-типа:

    template<JsonNullable T>
    void write_nullable(T const& t) {
        if (t.has_value()) {
            write(*t);
        } else {
            _out << "null";
        }
    }

Записи числового, строкового, булевого типов нерекурсивны:

    template<JsonNumber T>
    void write_number(const T t) {
        _out << t;
    }

    template<JsonString T>
    void write_string(T const& t) {
        _out << '"' << t << '"';
    }

    template<JsonBoolean T>
    void write_boolean(const T t) {
        if (t) {
            _out << "true";
        } else {
            _out << "false";
        }
    }

Запись массива достаточно проста - надо только правильно ставить запятые, разделяющие объекты:

    template<JsonArray T>
    void write_array(T const& t) {
        _out << '[';
        bool is_first_item = true;
        for (const auto& item : t) {
            if (is_first_item) {
                is_first_item = false;
            } else {
                _out << ',';
            }
            write(item);
        }
        _out << ']';
    }

Запись объекта - самая сложная, нужно проитерироваться по членам структуры и записать каждый член отдельно:

    template<JsonObject T>
    void write_object(T const& t) {
        _out << '{';
        bool is_first_member = true;

        template for (constexpr meta::info e : meta::members_of(^T)) {
            if constexpr (meta::is_data_member([:^e:])) {
                if (is_first_member) {
                    is_first_member = false;
                } else {
                    _out << ',';
                }

                _out << '"' << meta::name_of(e) << '"';
                _out << ':';
                write(t.[:e:]);
            }
        }

        _out << '}';
    }

Создадим модель данных - пусть это будет библиотека, у которой несколько книг, один адрес, и опционально "описание"

namespace model {

struct book {
    std::string name;
    std::string author;
    int year;
};

struct latlon {
    double lat;
    double lon;
};

struct library {
    std::vector<book> books;
    std::optional<std::string> description;
    latlon address;
};

} // namespace model

Зададим библиотеке адрес, добавим несколько книг, и выведем ее в формате JSON:

int main() {
    model::library l;
    l.address = model::latlon{.lat = 51.507351, .lon = -0.127696};
    l.books.push_back(model::book{
        .name = "The Picture of Dorian Gray",
        .author = "Oscar Wilde",
        .year = 1890,
    });
    l.books.push_back(model::book{
        .name = "Fahrenheit 451",
        .author = "Ray Bradbury",
        .year = 1953,
    });
    l.books.push_back(model::book{
        .name = "Roadside Picnic",
        .author = "Arkady and Boris Strugatsky",
        .year = 1972,
    });

    json::json_writer{std::cout}.write(l);
    std::cout << std::endl;
}

Программа выведет неотформатированный JSON:

{"books":[{"name":"The Picture of Dorian Gray","author":"Oscar Wilde","year":1890},{"name":"Fahrenheit 451","author":"Ray Bradbury","year":1953},{"name":"Roadside Picnic","author":"Arkady and Boris Strugatsky","year":1972}],"description":null,"address":{"lat":51.5074,"lon":-0.127696}}

{
    "books": [
        {
            "name": "The Picture of Dorian Gray",
            "author": "Oscar Wilde",
            "year": 1890
        },
        {
            "name": "Fahrenheit 451",
            "author": "Ray Bradbury",
            "year": 1953
        },
        {
            "name": "Roadside Picnic",
            "author": "Arkady and Boris Strugatsky",
            "year": 1972
        }
    ],
    "description": null,
    "address": {
        "lat": 51.5074,
        "lon": -0.127696
    }
}

Компиляция на godbolt

Если бы сериализацию/десериализацию надо было сделать в реальном проекте, я бы посоветовал добавить "прокладку" в виде существующей json-библиотеки, например nlohmann/json.

То есть мы бы переводили объект "нашей" структуры в объект из json-библиотеки, а этот объект уже конвертировался бы в строку. При десериализации наоборот - строка в json-объект, json-объект в "наш" объект.

Это нужно, чтобы не переизобретать велосипед - с "прокладкой" работать проще и надежнее, чем самому что-то парсить.

Такой же подход работает для XML, ORM в базу данных, и прочего.

Универсальный метод сравнения двух объектов

Возьмем model::book из предыдущего кода. Если мы попытаемся сравнить два объекта этого типа, то получим ошибку компиляции

    model::book a, b;
    std::cout << (a == b) << std::endl; // тут ошибка компиляции

Можно выработать свои правила для универсального сравнения:

1. Если объекты можно сравнить, то есть вызов a == b скомпилируется, то результат сравнения - вызов этого оператора.

2. Если объект - итерируемый контейнер (как std::vector), то проверим, что размеры совпадают, и сравним каждый элемент контейнера.

3. Иначе проитерируемся по членам типа и сравним каждый член отдельно.

Для первого и второго пункта концепты пришлось написать самому, так как существующие не нашел...

namespace bicycle {

template <class T>
constexpr bool equality_comparable = requires(const T& a, const T& b) {
    std::is_convertible_v<decltype(a == b), bool>;
};

template <class T>
constexpr bool iterable = requires(const T& t, size_t i) {
    t[i];
    std::begin(t);
    std::end(t);
    std::size(t);
};

} // namespace bicycle

Теперь напишем наш метод, как и планировали - с проверкой с первого по третий пункт? На самом деле нет - первый и второй пункт надо поменять местами

static_assert(    bicycle::equality_comparable<int>);
static_assert(    bicycle::equality_comparable<std::string>);
static_assert(    bicycle::equality_comparable<std::optional<std::string>>);
static_assert(    bicycle::equality_comparable<std::vector<model::book>>); // <<< :(
static_assert(not bicycle::equality_comparable<model::book>);
static_assert(not bicycle::equality_comparable<model::library>);

template< class T, class Alloc >
bool operator==( const std::vector<T,Alloc>& lhs,
                 const std::vector<T,Alloc>& rhs );

Напишем наш метод:

namespace equal_util {

template<typename T>
bool equal(const T& a, const T& b) {
    if constexpr (bicycle::iterable<T>) {
        if (a.size() != b.size()) {
            return false;
        }
        for (size_t i = 0; i < a.size(); ++i) {
            if (!equal(a[i], b[i]))
                return false;
        }
        return true;
    } else if constexpr (bicycle::equality_comparable<T>) {
        return a == b;
    } else {
        template for (constexpr meta::info e : meta::members_of(^T)) {
            if constexpr (meta::is_data_member([:^e:])) {
                if (!equal(a.[:e:], b.[:e:])) {
                    return false;
                }
            }
        }
        return true;
    }
}

} // namespace equal_util

Возможно, стоило бы для типов float и double сравнивать их разницу с эпсилоном... Но пока обойдемся без этих подарочков.

Проверим метод - в первый раз выведется true, во второй раз false, успех!

int main() {
    model::library a, b;

    a.address = model::latlon{.lat = 51.507351, .lon = -0.127696};
    b.address = a.address;

    a.books.push_back(model::book{
        .name = "The Picture of Dorian Gray",
        .author = "Oscar Wilde",
        .year = 1890,
    });
    b.books = a.books;

    std::cout << std::boolalpha;
    std::cout << equal_util::equal(a, b) << std::endl;
    b.books.clear();
    std::cout << equal_util::equal(a, b) << std::endl;
}

Компиляция на godbolt

Контейнер Dependency Injection

И наконец, мы сделаем собственный контейнер для Dependency Injection!

Этот паттерн программирования хардкорно используется, например, в Spring - самом популярном Java-фреймворке.

В модели управления обычно одни объекты зависят от других объектов. Далее будем писать "компонент" вместо "объект".

Смысл паттерна в том, что вместо того, чтобы компонент сам создавал зависимые компоненты, эти компоненты создавал бы фреймворк. И потом давал бы их компоненту через конструктор (все компоненты сразу) либо через сеттер-методы (по одному сеттер-методу на компонент).

Во многих случаях такой подход сильно упрощает программирование. В сложных проектах длина цепочки зависимостей может находиться за пределами возможностей человеческого мозга.

Создадим модель управления для сервиса а-ля "URL Shortener", который принимает длинные ссылки и отдает короткие (и наоборот). У нас будет, очень условно, четыре компонента (в реальности было бы побольше):

1. s3_storage - сервис, который умеет брать картинку из s3-хранилища и возвращать ее.

2. database - сервис-"прокладка" для работы с базой данных

3. link_shortener - сервис, принимающий длинную ссылку и возвращающий короткую (и наоборот). Зависит от database, где хранит соответствие между ссылками.

4. http_server - сервис, обрабатывающие запросы по http. Зависит от s3_storage (показ лого на сайте), link_shortener (понятно для чего), database (куда пишет всякую статистику про посетителя сайта).

Опишем компоненты в коде:

namespace component {

class database {
public:
    void post_construct() {
        /* тут инициализируем подключение к БД */
    }

    /* тут некие методы об операциях в БД */
};

class link_shortener {
public:
    void set_component(std::shared_ptr<database> component) {
        _database = std::move(component);
    }

    /* тут некие методы link_shortener. */ 
    /* метод post_construct() не нужен */

private:
    std::shared_ptr<database> _database;
};

class s3_storage {
public:
    /* тут некие методы s3_storage. */ 
    /* метод post_construct() не нужен */
};

class http_server {
public:
    void set_component(std::shared_ptr<s3_storage> component) {
        _s3_storage = std::move(component);
    }

    void set_component(std::shared_ptr<link_shortener> component) {
        _link_shortener = std::move(component);
    }

    void set_component(std::shared_ptr<database> component) {
        _database = std::move(component);
    }

    void post_construct() {
        /* тут поднимаем http-сервер и ждём запросы */
    }

private:
    std::shared_ptr<s3_storage> _s3_storage;
    std::shared_ptr<link_shortener> _link_shortener;
    std::shared_ptr<database> _database;
};

} // namespace component

Что должен сделать фреймворк:

1. Создать компоненты через std::make_shared, каждый компонент должен быть создан ровно один раз.

2. Вызвать set_component с готовыми зависимыми компонентами.

3. Когда все нужные set_component вызваны, вызвать метод post_construct, если он есть в классе. Сначала вызывается у зависимых компонент, потом у зависящих.

4. Когда "корневой компонент" (в нашем случае http_server) закончит работу post_construct, в правильном порядке уничтожить компоненты, чтобы на момент вызова деструктора все зависимые компоненты были "живы".

Создадим заготовку класса:

namespace dependency_injection {

static constexpr meta::info shared_ptr_refl = ^std::shared_ptr;

class components_builder {
public:
    template<typename Component>
    std::shared_ptr<Component> build() && {
        return build_component_impl<Component>();
    }

private:
    using ready_components_container = std::unordered_map<std::string_view, std::any>;
    static constexpr std::string_view COMPONENT_INJECTION_FUNCTION_NAME = "set_component";
    static constexpr std::string_view COMPONENT_POST_CONSTRUCT_FUNCTION_NAME = "post_construct";

private:
    // другие методы...
  
private:
    ready_components_container _ready_components;
};

} // namespace dependency_injection

Готовые компоненты хранятся в хешмапе. Значения хешмапы имеют тип std::any, потому что компоненты не имеют общего типа.

Создадим метод-"прокладку", который сначала ищет компонент в хешмапе, а если не найдет, то строит компонент:

    // don't build component again if already has one built
    template<typename Component>
    std::shared_ptr<Component> build_or_get_component() {
        std::shared_ptr<Component> component;

        constexpr std::string_view comp_name = meta::name_of(meta::entity_of(^Component));
        if (auto _ready_iter = _ready_components.find(comp_name); _ready_iter != _ready_components.end()) {
            component = std::any_cast<decltype(component)>(_ready_iter->second);
        } else {
            component = build_component_impl<Component>();
            _ready_components[comp_name] = component;
        }

        return component;
    }

Чтобы построить компонент, надо создать его объект через std::make_shared, потом построить все зависимые компоненты и вызвать для каждого set_component, потом вызвать метод post_construct при его наличии.

    template<typename Component>
    std::shared_ptr<Component> build_component_impl() {
        auto component = std::make_shared<Component>();
        build_dependent_components(*component);
        try_call_post_construct(*component);
        return component;
    }

Сделаем вспомогательный метод, который определяет, имеем ли мы перед собой рефлексию метода с нужным именем:

    template<meta::info R>
    static constexpr bool is_callable_function(std::string_view expected_function_name) {
        // drop special functions and non-public functions
        if constexpr (meta::is_function(R) && meta::is_public(R) && !meta::is_special_member_function(R)) {
            constexpr std::string_view function_name = meta::name_of(R);
            return function_name == expected_function_name;
        }
        return false;
    }

Как мы можем определить зависимые компоненты:

1. Ищем все методы с названием set_component. Пусть мы зафиксировали один такой метод.

2. Проверяем, что в этом методе ровно один параметр.

3. Тип этого параметра должен являться специализацией шаблона std::shared_ptr.

4. Класс, которым был специализирован шаблон - это класс компонента, который нужно создать (или взять готовый, если есть).

5. Вызываем set_component с компонентом из п. 4.

С этим планом сделаем метод build_dependent_components:

    template<typename Component>
    void build_dependent_components(Component& component) {
        template for (constexpr meta::info e : meta::members_of(^Component)) {
            // iterate through functions
            if constexpr (is_callable_function<e>(COMPONENT_INJECTION_FUNCTION_NAME)) {
                // the function should have exactly one parameter
                constexpr auto param_range = meta::parameters_of(e);
                static_assert(size(param_range) == 1, "Please pass only one parameter");
                constexpr meta::info param = *param_range.begin();

                // the type of the parameter should be std::shared_ptr<U>
                constexpr meta::info param_type = meta::type_of(param);
                static_assert(meta::is_specialization(param_type), "Please pass std::shared_ptr<component>");
                static_assert(meta::template_of(param_type) == shared_ptr_refl, "Please pass std::shared_ptr<component>");

                // obtain dependent component type
                using SharedPtrType = typename [:param_type:];
                using DependentComponentType = typename SharedPtrType::element_type;

                // build the dependent component (if not built yet) and give it to the original component
                auto dependent_component = build_or_get_component<DependentComponentType>();
                component.[:e:](dependent_component);
            }
        }
    }

Вызов post_construct выглядит проще:

    template<typename Component>
    void try_call_post_construct(Component& component) {
        template for (constexpr meta::info e : meta::members_of(^Component)) {
            if constexpr (is_callable_function<e>(COMPONENT_POST_CONSTRUCT_FUNCTION_NAME)) {
                constexpr auto param_range = meta::parameters_of(e);
                static_assert(size(param_range) == 0, "Please don't pass parameters in "post_construct"");
                component.[:e:]();
            }
        }
    }

Осталось только установить "корневой компонент" и запустить весь процесс:

int main() {
    dependency_injection::components_builder().build<component::http_server>();
}

Если для каждого компонента добавить лог имени вызываемого метода в конструкторе, деструкторе, set_component и post_construct, то можно увидеть, что именно делает фреймворк:

call "http_server::http_server()"
call "s3_storage::s3_storage()"
call "s3_storage::post_construct()" <<<<<<<<<< THE COMPONENT IS READY
call "http_server::set_component(std::shared_ptr<s3_storage>)"
call "link_shortener::link_shortener()"
call "database::database()"
call "database::post_construct()" <<<<<<<<<< THE COMPONENT IS READY
call "link_shortener::set_component(std::shared_ptr<database>)"
call "link_shortener::post_construct()" <<<<<<<<<< THE COMPONENT IS READY
call "http_server::set_component(std::shared_ptr<link_shortener>)"
call "http_server::set_component(std::shared_ptr<database>)"
call "http_server::post_construct()" <<<<<<<<<< THE COMPONENT IS READY
call "http_server::~http_server()"
call "link_shortener::~link_shortener()"
call "database::~database()"
call "s3_storage::~s3_storage()"

Фреймворк все делает правильно!

Из того, что можно добавить:

1. Проверку на циклы зависимостей - их быть не должно. Кажется, циклы возможно обнаружить в compile-time.

2. Можно зависеть от интерфейса, а не от реализации, "как в лучших домах Парижу".

Другие примеры рефлексивного программирования

Кроме примеров выше, я сделал hasattr.cpp - имитация методов hasattr и getattr из языка Python, а также opts.cpp - типизированный парсер командной строки.

Разбирать их я не стал, потому что новой информации там нет.

Все примеры доступны на github - ссылка.

Что хочется иметь от рефлексии в будущем?

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

Хочется, чтобы рефлексия умела работать с атрибутами, потому что без этого отнимается большой пласт крутых юзкейсов.

Когда рефлексия войдет в C++ - пока точно не известно, но вероятнее всего, успеют к стандарту C++26.