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

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

Шаблоны в 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-типов и написать обобщённый код без лишней потери производительности.

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