C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.

Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске обсудим непростую тему фич и идиом С++.

Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.

Будет субъективно, местами провокационно и точно полезно — чтобы вы посмотрели на привычные инструменты свежим взглядом и осознанно выбирали, на чём писать следующий проект.

---

Разделение по категориям — условное и субъективное

Мы разделили инструменты на четыре категории: 

FAIL — решения, которые когда-то были оправданным выбором за неимением альтернатив, но к 2026 году окончательно превратились в legacy и bad practice. Использовать их сегодня в продакшене — сомнительное удовольствие. Чаще всего честнее и полезнее поблагодарить эти инструменты за службу и отпустить без сожалений.

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

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

GOD — инструменты, которые делают своё дело максимально качественно и близко к идеалу. Минимум настроек, максимум пользы, предсказуемость, точность и элегантность. Они не пытаются быть всем и сразу, но внутри своей ниши это эталоны.

Ещё раз подчеркнём: к формату не стоит относиться слишком серьёзно. Наш тир-лист — не приговор и не догма, а приглашение к дискуссии и повод пересмотреть устоявшиеся привычки.

Итак, поехали!

FAIL

Макросы

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

Макросы дают разработчику большую свободу, но вместе с ней приносят серьёзные проблемы. Они не работают с namespace, игнорируют типизацию и ломают привычные механизмы языка. С появлением variadic templates во всех основных компиляторах необходимость в макросах заметно сократилась. Многие задачи, ради которых их использовали раньше, теперь решаются языковыми средствами.

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

iostream

Стандартная, уже довольно старая библиотека C++ для форматированного ввода/вывода данных. Её часто критикуют за производительность, особенно в высоконагруженных сценариях. Тем не менее iostream по-прежнему широко используется в промышленном софте — в том числе в программном обеспечении банкоматов и других embedded-систем.

Одна из ключевых проблем iostream — историческое наследие времён раннего C++, когда язык ещё активно оглядывался на C. В частности, в неё глубоко зашит std::locale, что усложняет контроль над производительностью и поведением вывода. Именно поэтому в современном C++ всё чаще стараются заменить iostream на более предсказуемые альтернативы вроде std::print и std::format, не завязанные на глобальное состояние.

Есть и практические ловушки. Например, достаточно один раз установить std::hex, и если забыть сбросить состояние потока, последующий вывод продолжит идти в шестнадцатеричном виде. Даже у printf, со всеми его недостатками, таких эффектов нет. Он не тащит за собой скрытое состояние.

Мы считаем, что iostream сегодня находится где-то на границе между MVP и FAIL: библиотеку по-прежнему используют, она работает, но количество проблем и ограничений делает её всё менее привлекательным выбором для новых проектов.

RTTI

Run-Time Type Information (RTTI) позволяет получать информацию о типах объектов во время выполнения программы. При этом важно понимать, что использование RTTI в C++ не всегда является осознанным выбором разработчика: как только в коде появляется виртуальная функция, в бинарник автоматически попадает информация о типе объекта — даже если вы явно этого не планировали и не запрашивали.

Виртуальные функции, виртуальное наследование и динамическое имя типа, которое вы можете получить из typeid — это немного разные вещи, которые в C++ склеены воедино. С одной стороны, немногие заморачиваются по поводу размеров бинарников, а с другой, в C++ хочется контролировать всё от и до. 

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

Если бы RTTI состоял только из виртуальных функций, было бы хорошо. Но оставшаяся часть, имя типа, которое можно получить динамически — достаточно редко используемая штука. Если бы это можно было разделить, то первое бы пошло в SENIOR, а второе — в FAIL.

Floating Point

Это типы данных для работы с дробными числами, позволяющие хранить вещественные значения с заданной точностью. Floating Point с нами давно, это отдельный стандарт, который поддерживается почти во всех языках программирования. Но у него есть нюансы.

Как разработчикам приложений, нам обычно хочется иметь число с плавающей точкой, которое компилятор знает, как оптимизировать, чтобы это хорошо и быстро работало. Но Floating Point в C++, C и многих других языках даёт не только вычисления с погрешностью, но и предоставляют вам уникальную возможность посадить уязвимости в код, о которых вы даже не знаете.

Например, Floating Point допускает значения вроде NaN — число, которое при сравнении с самим собой возвращает false. Это не просто математический курьёз, а реальный источник проблем: подобные свойства позволяют закладывать в код трудноуловимые логические «мины». Особенно неприятно, что какие-нибудь парсинги из JSON во Floating Point позволяют получить там NaN, что добавляет веселья, когда вы принимаете пользовательские данные по сети.

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

Если мы знаем два числа, то на этапе компиляции их не всегда можно складывать заранее, потому что из-за погрешностей нельзя менять порядок вычислений, даже если операция коммутативная. Складывая эти семь чисел через плюс, нельзя просто сложить сначала последние числа. Это очень сильно связывает руки компиляторам и мешает оптимизациям. Да и в целом наличие такой неопределённости в базовом низкоуровневом компоненте — это ужасно.

Отдельная боль — округление. Режим округления Floating Point — это глобальное состояние процессора, зачастую даже не thread_local. Если в одном участке кода нужен один режим округления, а в другом — другой, начинаются проблемы. Компилятор при этом не знает, какой режим округления будет активен во время выполнения, что ещё сильнее ограничивает возможности оптимизации.

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

MVP: имеет право на жизнь

CRTP

Curiously Recurring Template Pattern — это идиома C++, при которой класс наследуется от шаблонного базового класса, параметризованного самим этим классом.

Долгое время CRTP был вынужденной мерой. До появления deducing this, позволяющего передавать this как параметр шаблона, это был единственный способ реализовать ряд паттернов и добиться нужного поведения без виртуальных вызовов.

Но с появлением deducing this ситуация изменилась. Большая часть задач, ради которых использовали CRTP, теперь решается проще, прозрачнее и безопаснее — без шаблонной магии и без усложнения иерархий.

Поэтому вывод здесь довольно жёсткий: CRTP — это технический костыль своего времени. В современном C++ ему пора уступить место более понятным и выразительным языковым механизмам. По нашему мнению, CRTP находится где-то на границе между MVP и FAIL

Идиома стирание типов

Type erasure (стирание типов) — идиома C++, которая позволяет создавать полиморфные типы с семантикой значений, скрывая конкретную реализацию за единым интерфейсом.

Долгое время эта техника использовалась довольно ограниченно. Она сформировалась ещё в 90-х годах как идиома и шаблон проектирования, но оставалась нишевой. По-настоящему массовой она стала с появлением в стандартной библиотеке типов std::function и std::any в стандартах C++11/14/17. Именно они реализованы на основе стирания типов «под капотом».

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

Классический пример — std::function. Это универсальная обёртка для любых вызываемых объектов (указателей на функции, лямбд, функторов) с заданной сигнатурой. Она позволяет передавать такие объекты через единый, не шаблонный интерфейс, упрощая API библиотек и снижая связность кода. При этом внутрь std::function попадает не сам шаблонный объект, а конкретное инстанцирование вызова, полностью инкапсулированное за абстрактным интерфейсом.

PIMPL и FAST PIMPL

PIMPL (Pointer to IMPLementation) — это идиома C++, при которой детали реализации класса скрываются за указателем на внутренний тип. FAST PIMPL — её оптимизированный вариант, уменьшающий накладные расходы классического PIMPL.

В целом PIMPL решает сразу несколько системных проблем C++: ускоряет сборку, скрывает детали реализации из заголовков и упрощает поддержку бинарной совместимости. В эпоху крупных проектов и долгоживущих API это по-прежнему важные задачи, и именно под них PIMPL исторически и появился.

Главный минус классического PIMPL — накладные расходы: дополнительная индирекция, аллокации и усложнение кода. FAST PIMPL частично сглаживает эти проблемы за счёт оптимизаций, но полностью от них не избавляет.

Если смотреть на ситуацию в идеальном мире с повсеместной поддержкой C++-модулей, PIMPL и FAST PIMPL были бы попросту не нужны. Модули решают те же задачи — инкапсуляцию, ускорение сборки и контроль ABI — значительно более элегантным способом. В таком мире эту идиому вполне можно было бы отправить в FAIL.

Но мы живём в реальности, где модули всё ещё далеки от повсеместного использования, а продакшн-код приходится писать здесь и сейчас. Поэтому PIMPL и FAST PIMPL по-прежнему остаются рабочим инструментом. Не потому, что они удобны или красивы, а потому что часто являются единственным практичным вариантом.

Итоговая оценка — где-то между MVP и SENIOR: 

PIMPL + FAST PIMPL претендуют на категорию SENIOR не из-за удобства, а из-за необходимости использовать в продакшн решениях. Но из-за реализации дотягивают пока скорее только до MVP.

Модули

Система организации кода, в которой компоненты реализуются в изолированных единицах компиляции с явно заданными интерфейсами.

У C++ исторически есть серьёзная боль со скоростью сборки и управлением зависимостями заголовков. Именно эту проблему и призваны решать модули — при нормальной поддержке со стороны компилятора. И хотя на дворе начало 2026 года, поддержка модулей в компиляторах всё ещё далека от идеала и часто требует осторожности при использовании.

При этом модули ускоряют сборку от двух до десяти раз, в зависимости от архитектуры кода, глубины include-графа и размера проекта.

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

Да, у модулей по-прежнему есть шероховатости: нестабильная поддержка, особенности интеграции с существующими сборочными системами и легаси-кодом. Но при всех проблемах это один из немногих инструментов в C++, который одновременно лечит сразу две фундаментальные боли языка — медленные сборки и неконтролируемое расползание интерфейсов.

SENIOR: без него не обойтись

VARIADIC TEMPLATES

Это шаблоны, принимающие произвольное количество типов или аргументов. 

Например, если у нас функция, в которой сто параметров, то нам бы пришлось объявлять сто шаблонных функций под каждый. Это не только муторно писать, но даже поддерживать и читать. VARIADIC TEMPLATES позволяет нам реализовать все сто параметров одним объявлением шаблона.

До появления VARIADIC TEMPLATES такую функциональность эмулировали с помощью макросов и это было ужасно, нечитаемый безобразный код, который невозможно дебажить. Всё делалось через библиотеку boost preprocessor. На этом фоне VARIADIC TEMPLATES стали огромным шагом вперёд — типобезопасным, выразительным и встроенным в язык решением. 

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

Итог простой: VARIADIC TEMPLATES — мощный и полезный инструмент, особенно для библиотек и обобщённых интерфейсов. Но, как и любой мощный механизм в C++, они требуют дисциплины и осознанного использования.

Оператор spaceship (<=>)

Оператор трёхстороннего сравнения (<=>) позволяет автоматически генерировать полный набор операторов сравнения и гарантировать их логическую согласованность.

Представим, что вы хотите реализовать тип, который ведёт себя как число и должен корректно сравниваться с другими такими же типами. До появления <=> это означало ручную перегрузку целого зоопарка операторов: <, <=, >, >=, ==, !=. И это только для сравнения объектов одного типа. Если же типов несколько, количество перегрузок начинает расти комбинаторно. Поддерживать такой код — боль.

С оператором spaceship всё сводится к одной строке: объявляем <=> = default, и компилятор сам генерирует корректные операции сравнения. Это радикально снижает количество boilerplate-кода и делает намерения разработчика прозрачными. 

Но есть нюанс: вместе с внедрением <=> были изменены правила генерации некоторых операторов по умолчанию, в том числе operator==. В редких и экзотических случаях это приводит к неприятным эффектам: код, который раньше корректно работал, продолжает компилироваться, но при сравнении может уйти в бесконечную рекурсию. Такие баги особенно неприятны тем, что проявляются не на этапе компиляции, а уже во время выполнения.

Итог: оператор <=> — сильный и полезный инструмент, который значительно упрощает реализацию корректных сравнений. Он заслуженно попадает в категорию SENIOR: почти идеален, но есть случаи, о которых важно помнить при использовании в продакшене.

Исключения

Исключения позволяют обрабатывать ошибки времени выполнения без избыточного boilerplate — в отличие от классических кодов возврата из C. 

На старте у исключений в C++ было немало проблем. Не с идеей — она как раз сильная: исключения позволяют отделить обработку ошибок от бизнес-логики и сделать код заметно чище. Основные сложности были в реализации: первые версии механизма были тормознутыми и тяжёлыми.

Со временем ситуация улучшилась. Компиляторы научились так оптимизировать код, чтобы исключения практически не влияли на «холодные» ветки исполнения. В результате в ряде сценариев код с исключениями может работать даже быстрее, чем варианты с кодами возврата. По пути были эксперименты с динамическими спецификациями исключений в сигнатурах функций — идея выглядела красиво, но на практике оказалась неудачной, и от неё закономерно отказались.

Сейчас это довольно удобный механизм, но проблем в нём хватает. Например, возможность бросать и ловить буквально что угодно, а не только типизированные исключения. Выстрелить себе в ногу — проще простого. Добавьте к этому нюансы с хитростями в деструкторах. Альтернативы у исключений нет, поэтому это решение в любом случае используется на проде. Бизнес-логику без исключений может и можно исхитриться написать, но это будет очень сложно.

При этом даже сейчас многие компиляторы всё ещё неохотно оптимизируют код, связанный с исключениями. Именно поэтому их нельзя отнести к категории GOD: инструмент полезный, но не идеальный.

GOD: идеальные решения

RAII

Фундаментальная идиома C++, в которой владение ресурсом жёстко связано с временем жизни объекта. Ресурс захватывается при инициализации объекта и гарантированно освобождается в деструкторе независимо от того, как происходит выход из области видимости: через return или из-за исключения.

Главная ценность RAII в том, что управление ресурсами перестаёт быть вопросом дисциплины программиста и становится свойством языка. Память, файловые дескрипторы, мьютексы, сокеты и другие ресурсы подчиняются единым правилам, что устраняет целый класс ошибок — утечки, двойное освобождение и забытые unlock.

RAII делает код безопасным в присутствии исключений, упрощает модель владения и отлично масштабируется от локальных объектов до сложных абстракций. На этой идиоме построена значительная часть стандартной библиотеки: std::unique_ptr, std::lock_guard, std::scoped_lock, std::fstream и многие другие типы.

Это не надстройка и не соглашение, а базовая идея C++, пережившая десятилетия и не потерявшая актуальности.

Вердикт: GOD — эталонная идиома, без которой современный C++ невозможно представить.

Лямбды

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

Это один из тех инструментов, без которых сегодня уже сложно представить современный C++. Лямбдам, безусловно, есть куда развиваться, но даже в текущем виде это настолько удачное решение, что его можно отнести к (почти!) идеальным решениям.

Времена, когда лямбд не существовало, вспоминают с содроганием. Чтобы реализовать похожее поведение, приходилось писать вложенные структуры, перегружать operator(), а иногда ещё и наследоваться от std::unary_function или std::binary_function. Такой код был громоздким, плохо читаемым и далеко не всегда корректно работал. На фоне этого лямбды стали настоящим облегчением — компактным, выразительным и понятным способом описывать локальную логику.

Конечно, у лямбд есть минусы. Например, сейчас невозможно захватывать часть переменных как const, а часть — как mutable. Если лямбда объявлена mutable, всё, что она захватывает, теряет константность. Этот недостаток планируют исправить в будущих стандартах (ориентировочно C++29), но пока приходится с ним мириться.

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

Вердикт: уверенный GOD — один из самых удачных и практичных элементов современного C++.

Namespaces

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

Очень полезная вещь! Просто возьмите любую библиотеку и представьте необходимость везде писать префикс этой библиотеки, чтобы не случился конфликт имён. Namespaces эту проблему решают элегантно и масштабируемо.

Namespaces позволяют делать хитрые вещи с argument-dependent name lookup (ADL). Разработчик может управлять тем, участвует ли функция в ADL: явно указывая namespace при вызове или, наоборот, полагаясь на механизм поиска по аргументам. Это позволяет строить гибкие и выразительные интерфейсы, особенно в шаблонных библиотеках и стандартной библиотеке.

Также namespaces дают возможность изолировать вспомогательные функции и детали реализации, полностью исключив их из ADL. Для авторов библиотек и фреймворков (например, вроде Boost) это критически важный инструмент для управления API и предотвращения неожиданных коллизий.

К несчастью, многие порой перебарщивают с количеством Namespace и их вложенностью, но это не проблема языка.

Вердикт: надёжный и необходимый инструмент, без которого невозможно представить современный C++.

Финал

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

Делитесь в комментариях своим мнением: какие идиомы вы бы без сожаления отправили в FAIL, что для вас — безусловный GOD, и с чем вы продолжаете жить, потому что «так устроен реальный прод».

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

YouTube

RuTube