Шаблоны C++ как инструмент архитектуры: compile-time dispatch, type traits и type erasure

matweu4 часа назад

Шаблоны C++ как инструмент архитектуры: compile-time dispatch, type traits и type erasure

Уровень сложностиСреднийВремя на прочтение9 минОхват и читатели5KC++*Научно-популярноеВсех приветствую! Я неоднократно встречал разработчиков, которые говорили, что метапрограммирование — это моветон, а шаблоны только усложняют код. Я понимаю, откуда берётся такое мнение потому, что при неаккуратном использовании шаблоны действительно могут сделать код сложным и тяжёлым для чтения.

Но, на мой взгляд, проблема не в самом инструменте, а в том, как именно его применяют.

Шаблоны в C++ - это не только std::vector и универсальные функции. В серьёзном C++ они часто используются как архитектурный механизм, позволяют переносить часть решений из runtime в compile-time, задавать контракты на уровне типов, собирать поведение из политик и писать обобщённый код без лишней runtime-стоимости.

Где метапрограммирование действительно нужно

Главное, что хочу сказать:

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

Но есть случаи, где compile-time подход действительно оправдан.

Если разные типы данных имеют разные возможности, лучше выразить это на уровне типов, а не держать всё в одной универсальной структуре.

Например:

struct EventA { std::uint64_t count = 0; double value = 0.0; };

struct EventB {
std::uint64_t count = 0;
double value = 0.0;
double rate = 0.0;
};

struct EventC {
std::uint64_t count = 0;
double value = 0.0;
std::string label;
};У всех событий есть count и value, но дополнительные поля отличаются. Если положить всё в одну структуру с enum, корректность будет держаться на соглашениях. В добавок если разделить типы, компилятор сам начнёт защищать от некорректных обращений.

Когда нужна общая логика для разных типов

template <typename Event> void process(const Event& event) {
std::cout << event.count << std::endl;
std::cout << event.value << std::endl;
}Для каждого конкретного Event, с которым будет вызвана эта функция, компилятор создаст свою версию. Он видит реальный тип и может оптимизировать код как работу с обычной конкретной структурой. На практике такой подход часто читается проще, чем набор почти одинаковых перегрузок:

void process(const EventA& event);
void process(const EventB& event);
void process(const EventC& event);Если логика у типов общая, шаблон позволяет описать её один раз и не дублировать код.

Когда нужны compile-time контракты

В функции выше template void process(const Event& event) имеются скрытые требования к типу. Она ожидает, что у объекта есть поля count и value.

В С++20 нам завезли concept и благодаря им эти требования можно выразить явно:

template <typename T>
concept BasicEvent = requires(T& event) {
{ event.count } -> std::convertible_to<std::uint64_t>;
{ event.value } -> std::convertible_to<double>;
};Немного подправим код и получим в результате:

template <BasicEvent Event>
void process(const Event& event) {
std::cout << "count = " << event.count << std::endl;
std::cout << "value = " << event.value << std::endl;
}И тут мы получаем уже не просто шаблонность, а контракт на уровне компиляции!

Например, структура EventA этому контракту соответствует, у нее есть поле count, которое приводится к std::uint64_t и поле value, которое приводится к double.

Теперь специально изменим контракт так, чтобы он больше не подходил для EventA:

template <typename T>
concept BasicEvent = requires(T event) {
{ event.count } -> std::convertible_to<std::string>;
{ event.value } -> std::convertible_to<double>;
};Теперь мы требуем, чтобы event.count можно было привести к std::string. Но в EventA поле count имеет тип std::uint64_t, поэтому тип больше не удовлетворяет BasicEvent.

При попытке вызвать функцию:

EventA a; process(a);компилятор выдаст ошибку:

./m.cpp: In function ‘int main()’:
./m.cpp:40:17: error: no matching function for call to ‘process(EventA&)’
40 | process(a);
| ~~~~~~~~~~~~^~~
./m.cpp:31:34: note: candidate: ‘template<class Event> requires BasicEvent<Event> void process(const Event&)’
31 | template <BasicEvent Event> void process(const Event &event)
| ^~~~~~~~~~~~
./m.cpp:31:34: note: template argument deduction/substitution failed:
./m.cpp:31:34: note: constraints not satisfied
./m.cpp: In substitution of ‘template<class Event> requires BasicEvent<Event> void process(const Event&) [with Event = EventA]’:
./m.cpp:40:17: required from here
./m.cpp:26:9: required for the satisfaction of ‘BasicEvent<Event>’ [with Event = EventA]
./m.cpp:26:22: in requirements with ‘T event’ [with T = EventA]
./m.cpp:27:13: note: ‘event.count’ does not satisfy return-type-requirement
27 | { event.count } -> std::convertible_to<std::string>;
| ~~~~~~^~~~~
cc1plus: note: set ‘-fconcepts-diagnostics-depth=’ to at least 2 for more detailИ это как раз тот момент, ради которого полезны concept, компилятор не просто говорит, что где-то внутри шаблонной функции что-то сломалось. Он показывает, что тип EventA не прошёл проверку контракта BasicEvent.

В данном случае проблема конкретно здесь:

{ event.count } -> std::convertible_to<std::string>;То есть event.count существует, но его тип не соответствует требованию. Мы попросили std::string, а получили std::uint64_t

Такой подход делает шаблонный код понятнее и требования к типу находятся рядом с объявлением функции, а ошибка возникает на этапе компиляции и указывает именно на нарушенный контракт.

Когда поведение можно собрать на этапе компиляции

Если класс содержит много if, switch и enum-конфигураций, часто это сигнал, что часть поведения можно вынести в policy-типы.

template <typename FilterPolicy, typename ScorePolicy, typename ExportPolicy>
class Pipeline {
public:
void process(double value) {
if (!filter_.accept(value)) {
return;
}

auto result = score_.calculate(value);

if (result.active) { export_.send(result); } }

private:
FilterPolicy filter_;
ScorePolicy score_;
ExportPolicy export_;
};Конкретное поведение собирается на этапе компиляции:

using DebugPipeline = Pipeline<ThresholdFilter,SimpleScore,ConsoleExport>;Выигрыш в том, что внутри нет виртуальных вызовов и runtime-ветвления по типу поведения. Компилятор видит весь pipeline целиком.

Compile-time dispatch через if constexpr

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

Например, у EventB есть rate, а у EventC есть label.

Вот тут то к нам и приходит на помощь if constexpr вместе с std::is_same_v<>

template <typename Event> void process_event(const Event &event)
{
std::cout << "count = " << event.count << std::endl;
std::cout << "value = " << event.value << std::endl;
if constexpr (std::is_same_v<Event, EventB>)
{
std::cout << "rate = " << event.rate << std::endl;
}
else if constexpr (std::is_same_v<Event, EventC>)
{
std::cout << "label = " << event.label << std::endl;
}
}Здесь if constexpr (std::is_same_v<>) проверяет условие на этапе компиляции.

Если Event - это EventB, компилятор оставит ветку с rate. Если Event - это EventC, оставит ветку с label. А для EventA обе дополнительные ветки будут отброшены.

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

В runtime-подходе поведение обычно выбирается через switch, enum или виртуальные функции. В compile-time-подходе выбор происходит через типы, а неподходящие ветки просто не попадают в итоговую инстанциацию шаблона.

Type traits

В предыдущем примере мы проверяли конкретные типы напрямую:

std::is_same_v<Event, EventB>

Для небольшого примера это нормально. Код короткий, типов мало, всё легко держать в голове.

Но если система растёт, такие проверки быстро начинают засорять код. В обработчике появляется всё больше условий вида: «если это EventB», «если это EventC», «если это EventD». В итоге функция начинает знать слишком много о конкретных типах.

Для решения этого можно вынести описание свойств типа в отдельный traits:

template <typename Event>
struct event_traits;А дальше прост описать свойства для каждого события:

template <> struct event_traits<EventA>
{
static constexpr std::string_view name = "event_a";
static constexpr bool has_rate = false;
static constexpr bool has_label = false;
};
template <> struct event_traits<EventB>
{
static constexpr std::string_view name = "event_b";
static constexpr bool has_rate = true;
static constexpr bool has_label = false;
};
template <> struct event_traits<EventC>
{
static constexpr std::string_view name = "event_c";
static constexpr bool has_rate = false;
static constexpr bool has_label = true;
};Теперь обработчик можно написать чуть чище:

template <typename Event> void process_v2(const Event &event)
{
using traits = event_traits<Event>;
std::cout << "type = " << traits::name << '\n';
std::cout << "count = " << event.count << '\n';
std::cout << "value = " << event.value << '\n';
if constexpr (traits::has_rate)
{
std::cout << "rate = " << event.rate << '\n';
}
if constexpr (traits::has_label)
{
std::cout << "label = " << event.label << '\n';
}
}Здесь обработчик уже не привязан напрямую к EventB или EventC. Он работает не с именами конкретных типов, а с их свойствами.

Это делает код гибче. Например, если появится новый тип события:

struct EventD {
std::uint64_t count = 0;
double value = 0.0;
double rate = 0.0;
double deviation = 0.0;
};мы можем просто описать его свойства:

template <>
struct event_traits<EventD> {
static constexpr std::string_view name = "event_d";
static constexpr bool has_rate = true;
static constexpr bool has_label = false;
};И общий обработчик продолжит работать без изменений.

Type erasure

Это компромисс между template и virtual. Шаблоны хороши, когда конкретный тип известен на этапе компиляции. Но иногда нужно хранить разные реализации в одном контейнере или выбирать поведение в runtime. Можно использовать классический виртуальный интерфейс:

struct IProcessor {
virtual void process(double value) = 0;
virtual ~IProcessor() = default;
};Но есть другой подход - type erasure, он позволяет спрятать конкретный тип за единым интерфейсом, не заставляя сам тип наследоваться от базового класса.

Простой пример:

class AnyProcessor
{
public:
template <typename Processor>
AnyProcessor(Processor processor) : object_(std::make_shared<Model<Processor>>(std::move(processor))){}
void process(double value) { object_->process(value); }

private:
struct Concept
{
virtual void process(double value) = 0;
virtual ~Concept() = default;
};

template <typename Processor>
struct Model final : Concept
{
explicit Model(Processor processor) : processor_(std::move(processor)) {}

void process(double value) override { processor_.process(value); }

Processor processor_; };

std::shared_ptr<Concept> object_;
};Теперь конкретные типы не обязаны наследоваться от общего интерфейса:

struct LoggingProcessor
{
void process(double value) { std::cout << "value = " << value << std::endl; }
};

struct CountingProcessor { std::size_t count = 0;

void process(double) { ++count; } };Их можно хранить единообразно:

std::vector<AnyProcessor> processors;

processors.emplace_back(LoggingProcessor{}); processors.emplace_back(CountingProcessor{});

for (auto& processor : processors) {
processor.process(42.0);
}Код может показаться на первый взгляд трудным, но что здесь произошло:

• LoggingProcessor и CountingProcessor не знают про AnyProcessor
• им не нужен общий базовый класс
• внешний код работает с единым типом AnyProcessor
• внутри используется runtime dispatch, но он локализован

Когда лучше virtual, когда template, а когда type erasure

Type erasure хорошо подходит для мест, где системе действительно нужна гибкость во время выполнения: конфигурация, плагины, общий контейнер с разными обработчиками или внешний API.

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

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

Шаблоны дают compile-time polymorphism(статический полиморфизм): тип известен на этапе компиляции, и компилятор может собрать специализированный код под конкретный случай.

Виртуальные функции дают runtime polymorphism(динамический полиморфизм): конкретная реализация выбирается во время выполнения через общий базовый интерфейс.

Type erasure находится где-то между ними. Он тоже даёт runtime-гибкость, но при этом не заставляет пользовательские типы наследоваться от базового класса. Мы просто прячем конкретный тип за общей обёрткой.

Упрощённо: template - выбор типа в compile-time, максимум оптимизации virtual - выбор реализации в runtime через общий базовый класс type erasure - runtime-обёртка без наследования в пользовательских типах

То есть практическое правило можно сформулировать так: внутри горячего пути — шаблоны, на стабильных runtime-границах — virtual, а там, где хочется runtime-гибкости без обязательного наследования, — type erasure.

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

Но в правильном месте шаблоны решают вполне практические задачи. Они позволяют перенести часть решений на этап компиляции, убрать лишние runtime-проверки, описать требования к типам через concepts, собрать поведение из policy-типов и написать обобщённый код без лишней потери производительности.

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

Жуков Матвей /НИУ МЭИ ИВТИ /Кафедра управления и интеллектуальных технологий

C++ РазработчикТеги:• шаблоны c++
• метапрограммирование
• шаблоны
• c++
• c++20
• type erasureХабы:• C++
• Научно-популярное