[CppCon 2017] Herb Sutter: Метапрограммирование и кодогенерация в C++


Продолжаю серию публикаций Fil по CppCon 2017. В докладе представлены ранние наработки по добавлению рефлексии и кодогенерации в C++, а также по метаклассам, которые позволят генерировать части классов C++. В стандарт эти новшества попадут не ранее, чем в C++23.


Предисловие: операторы сравнения


Пусть мы хотим написать класс, объекты которого можно сравнивать, например, класс строки, не чувствительной к регистру — CIString (Case-Insensitive String). Для этого, как минимум, нам потребуется написать 6 операторов сравнения: ==, <, !=, >, >=, <=. Причём весь код, кроме первых двух, будет абсолютно шаблонным. Если надо уметь сравнивать нашу строку с const char* без копирования, то добавьте ещё 12 операторов.


Проблема дублирования кода в операторах сравнения стояла настолько остро, что было написано предложение к стандарту C++, добавляющее в язык так называемый "spaceship operator":


class CIString {
    string s;
public:
    // ... остальные функции ...
    std::weak_ordering operator<=>(const CIString& b) const { ... }
    std::weak_ordering operator<=>(const char* b) const { ... }
};

Мы пишем одну функцию <=>, где возвращаем std::weak_ordering::less, ::equivalent или ::greater, а компилятор генерирует реализации всех функции сравнения. Поддерживаются 5 основных типов сравнения, в том числе, std::strong_ordering и генерация только функций ==/!=.


Предложение о "spaceship operator" имеет ценность само по себе, но, как будет показано далее, с помощью метаклассов можно реализовать и его, и много других сценариев кодогенерации, причём на чистом C++, без необходимости встраивать их в компилятор или стандарт языка.


Рефлексия


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


Замечание: это очень ранняя версия предложения к стандарту, и $expr могут заменить на reflect(T), или вроде того.


Например, получить названия переменных произвольного enum можно с помощью метода variables():


template<typename E>
void print_strings() {
    for (auto o : $E.variables())
        cout << o.name() << endl;
}

enum class state { started = 1, waiting, stopped };
print_strings<state>();  //=> started waiting stopped

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


Кодогенерация (injection)


constexpr-блок может находиться в любом месте программы: в функции, в классе и т.д. Вот как это выглядит:


// обычный код
constexpr {
    // код, выполняемый при компиляции
}
// обычный код

Конструкция -> { ... } используется внутри блока constexpr, чтобы вставить на его месте обычный код:


constexpr {
    // ...
    -> {
        // обычный код
    }
    // ...
}

Пример: печать названия конкретной переменной перечисления


template<Enum E>   // почему бы не использовать ещё и концепты?
auto to_string(E value) {
    switch (value) {
        constexpr {
            for (auto o : $E.variables())
                -> { case o.value(): return o.name(); }
        }
    }
}

enum class state { started = 1, waiting, stopped };
cout << to_string(state::stopped);   //=> stopped

После предварительной обработки компилятор получит код, эквивалентный расписанному вручную switch.


Хороший вопрос — как отлаживать такой код? Без специальной поддержки со стороны отладчика, позволяющей взглянуть на сгенерированный код, отлаживать такие программы будет тяжело. Тем не менее, функция отладки кода, выполняющегося на этапе компиляции, была бы в любом случае полезна, ровно как и отладки кода, сгенерированного компилятором (многие хотели бы видеть default-конструкторы и операторы копирования при отладке).


Метаклассы


Определение метакласса (не путать с метатипом) начинается с ключевого слова $class, внутри можно определять генерируемые функции и условия, накладываемые на класс. При определении обычного класса можно вместо class указать имя метакласса, чтобы с его помощью преобразовать код класса. Выглядит это так:


$class interface {
    // только публичные чисто виртуальные функции
    // не содержит переменные, конструкторы копирования и перемещения
    // виртуальный деструктор
};

interface Shape {
    int area() const;
    void scale_by(double factor);
};

Такое определение Shape эквивалентно следующему:


class Shape {
public:
    virtual int area() const = 0;
    virtual void scale_by(double factor) = 0;
    virtual ~Shape() noexcept { };
};

В определении interface можно использовать constexpr-блоки и рефлексию, а также получать и модифицировать "свой" метатип:


$class interface {
    ~interface() noexcept { }
    constexpr  {
        compiler.require($interface.variables().empty(),
            "interfaces may not contain data members");
        for (auto f : $interface.functions()) {
            compiler.require(!f.is_copy() && !f.is_move(),
                "interfaces may not copy or move; consider a virtual clone()");
            if (!f.has_access()) f.make_public();
            compiler.require(f.is_public(), "interface functions must be public");
            f.make_pure_virtual();
        }
    }
};

Изменять произвольный класс уже после объявления невозможно, то есть ODR остаётся в силе.


Некоторые размышления о метаклассах


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


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


Примеры метаклассов


value


value Point {
    int x = 0;
    int y = 0;
    Point(int, int);
}

То, что Point является value, означает, что у него определены конструктор по умолчанию, операции копирования/перемещения и сравнения; гарантируется отсутствие виртуальных функций.


На примере value была показана композиция ("наследование") метаклассов:


$class basic_value { ... }
$class ordered { ... }
$class value : basic_value, ordered { }

Понятно, что не нужно никакого operator<=>, чтобы использовать ordered и генерировать операторы сравнения на основе полей класса.


literal_value


Планируется, что с помощью метаклассов можно будет генерировать и вспомогательные классы/функции, вроде swap и специализации std::hash. Тогда при помощи гипотетического метакласса literal_value можно будет написать простое и красивое определение std::pair, которого этот класс заслуживает:


template<class T1, class T2>
literal_value pair {
    T1 first;
    T2 second;
};

enum_class


То, что в языке C++ нет разделения на классы, интерфейсы и прочее, как в Java — это достоинство, так что теперь все пользовательские типы можно определять при помощи ключевого слова class… Кроме перечислений! К счастью, метаклассы — достаточно мощный инструмент, чтобы определить enum class. В результате можно будет писать:


enum_class state {
    auto started = 1, waiting, stopped;
};
state s = state::started;
while (s != state::waiting) { ... }

Эти enum_class могут быть даже лучше, чем существующие, за счёт дополнительных автоматически генерируемых функций и информативных сообщений об ошибках.


flag_enum


Значения flag_enum можно использовать как множества флагов, с операциями |, &, ^:


flag_enum openmode {
    auto in, out, binary, ate, app, trunc;   // 1, 2, 4, 8, 16, 32
};
openmode mode = openmode::in | openmode::out;
assert(mode != openmode::none);
assert(mode & openmode::out);

property (свойства)


classx MyClass {
    property<int> value { };  // get/set по умолчанию
    // ...
};

Маркер property<> используется метаклассом classx для генерации свойства:


class MyClass {
    int value;
public:
    void set_value(int v) { value = v; }
    int get_value() const { return value; }
};

Также при определении property можно задать свои функции get/set.


QClass


Qt использует утилиту moc, которая по определению класса генерирует данные для рефлексии времени выполнения, свойства и прочее. Метакласс QClass мог бы со всем этим справиться, позволяя собирать код, использующий Qt, только при помощи компилятора C++:


QClass MyClass {
    property<int> value { };
    signal mySignal();
    slot mySlot();
};

Помимо Qt moc, метаклассы позволят избавиться от нагромождения макросов и от проприетарных расширений языка, вроде WinRT и C++/CX.


podio


Библиотека podio, работающая с физикой частиц, использует YAML-файлы специального вида для определения структур данных:


ExampleHit:
    Description: "Example Hit"
    Author: "B. Heigner"
    Members:
        - double x
        - double y
        - double z
        - double energy

При этом на выходе генерируется сразу 5 классов: X, XCollection, XConst, XData, XObj. Утверждается, что с помощью метакласса получится делать то же самое.


CRTP


CRTP — это техника, при которой базовому классу передаётся производный в качестве шаблонного параметра:


template<typename Derived>
class EqualityComparable {
public:
    friend bool operator !=(const Derived& a, const Derived& b)
    { return !(a == b); }
};

class X : public EqualityComparable<X> {
public:
    friend bool operator==(const X& a, const X& b) { ... }
};

Фактически, мы уже используем некоторое подобие метаклассов в своих проектах. Только вот в достаточно сложном коде с шаблонами сообщения об ошибках оставляют желать лучшего. С появлением метаклассов CRTP уйдёт в прошлое.


Демонстрация


Herb продемонстрировал модификацию Clang, поддерживающую всё, что было показано выше, кроме генерации нескольких классов/функций из одного класса. Код, полученный после применения метакласса, можно просматривать и отлаживать.


Вопросы


Что если N компаний определят interface?


С классами строк уже это происходит, но это не значит, что от обычных классов надо отказаться. Основные метаклассы, вроде interface, можно будет добавить в std.


Какова польза от возможности определения interface в коде C++, если вы всё равно хотите стандартизировать некоторые популярные метаклассы?


Чтобы сейчас внести в стандарт interface, потребуется огромное количество времени, и проблема, связанная, с его отсутствием в языке, не настолько велика, чтобы кто-либо стал ей заниматься. Если же interface можно будет реализовать в 10 строк C++, то он пролетит через комитет стандартизации "со свистом".


Вы говорили, что метаклассы, определяющие сущности C++ в самом C++, лучше, чем определение их в стандарте. Также вы говорили, что язык стандарта C++ очень сложен. Не получится ли, что C++ усложнится до уровня языка стандарта C++?


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


Метаклассы модифицируют свой класс "на месте". Не было бы лучше, если бы у метакласса был "входной класс", и он генерировал бы код в "выходном классе"?


Да, мы собираемся поменять синтаксис, чтобы всё работало именно так. Выходной класс будет называться $prototype. Вначале он будет пустым, и метакласс будет вставлять в его определение строки одну за другой.


Вы сказали, что из одного метакласса можно будет генерировать несколько классов. Значит ли это, что все классы будут вложены в основной, или это будут отдельные классы?


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


Если literal_value окажется в стандарте, будет ли класс std::pair действительно изменён так, как было показано?


Если удастся определить literal_value так, чтобы в точности соответствовать текущему поведению std::pair, то да.


Получится ли полностью избавиться ото всех приёмов с шаблонами при генерации кода C++?


Шаблоны будут использоваться с метаклассами. Посмотрите пример с property<>.


Не получится ли так, что в каждой компании будет свой "обязательный" базовый метакласс, от которого должны будут наследоваться все классы, что приведёт к фрагментации языка?


Это уже происходит, и это называется "корпоративный стиль кода". Отличие в том, что он описывается словами и, возможно, проверяется различными инструментами. Теперь он будет соблюдаться более строго, предсказуемо и корректно. Когда мы тестировали удобство использования метаклассов на реальных проектах, мы обнаружили, что в каждом проекте им нашлось различное применение. Например, один из проектов включал библиотеку для управления роботом, которая требовала, чтобы все ваши классы следовали определённому шаблону. Сейчас они следят за соблюдением этих правил вручную. Периодически о них забывают, появляются трудноотлавливаемые ошибки и т.д. С помощью всего одного метакласса в 20-30 строк кода они могли бы устранить эту проблему раз и навсегда.


CRTP — отличная техника, похожая на метаклассы, работающая уже сейчас. Если её дополнить рефлексией и constexpr-блоками, то у них будет столько же возможностей, что и у метаклассов. Зачем тогда они нужны?


У метаклассов больше возможностей. CRTP — это замечательный "хак", но шаблоны изначально не были для этого предназначены, это недостаточно точный и функциональный инструмент. Например, CRTP позволяет по ошибке переопределить генерируемые методы в производном классе. Используя CRTP, не получится определять вспомогательные глобальные функции и классы.

  • +14
  • 6,7k
  • 7
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 7
  • +1
    Столько вкусных фич! Даже не верится, что это будет все еще обеспечивающий высокую производительность C++. Надеюсь увидеть это в стандарте (и поддержку компиляторами) как можно быстрее.
    • 0
      Будет забавно, если мы напишем про одно и то же выступление :) Предлагаю уведомлять друг друга о начале работы
      • 0
        В стандарт эти новшества попадут не ранее, чем в C++23

        Через шесть лет!?? Это же просто вечность в IT…
        • 0
          к тому времени уже C# .NET Core 2.0 будет полностью компилиться в натив через C++
          на данный момент github.com/dotnet/corert пока еще сырой в этом плане
        • –4
          Это конечно все конечно очень круто, но практика показывает, что 99% людей не нужен непосредственный доступ к самой модели: им просто нужно что-то генерить, быстренько, текстовой строкой. И вот тут-то можно посмотреть на язык D, который просто дает возможность выдавать строку и вставлять ее в сорцы на этапе компиляции. Так же работает и студийный Т4, который по сути просто генерит текст. Магия связаная с обходом AST никогда почему-то не задается вопросом, а зачем навешивать проперти вокруг полей если можно все сразу — и поля и проперти — описать одновременно. Это конечно очень круто что так можно делать, но мне кажется мало кто будет этим реально пользоваться. Самое главное что для инструментов анализа, например, метаклассы намного более болезненные чем просто emit текста (ровно как и препроцессор), потому что нужно все эти сложные конструкты парсить и разворачивать на этапе компиляции, дабы получать для них точные анализы, фиксы итд.
          • 0
            Правильно ли я понял что это похоже на Lombok для Java? Там идёт расширения языка за счёт аннотаций, которые применяются на этапе компиляции.
            @Data public class Human{
              private String name;
              private int age;
            }

            Создаст сеттеры, геттеры, методы toString, equals и hashCode.
            • 0

              Да. Насколько я вижу, по сравнению с Java, в предложенном варианте метаклассов есть, как минимум, 2 ограничения:


              1. Метаклассы применимы только для классов. Поля и методы так аннотировать не получится. Результат — появление метаклассов вроде classx, где из-за одной небольшой фичи приходится добавлять метакласс с её поддержкой
              2. Не более 1 метакласса на класс. Чтобы использовать несколько сразу, придётся писать код вида:
                $class MyClassMeta : classx, value {};
                MyClassMeta MyClass { ... };

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