Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. После большого релиза 🐙 userver прошло почти два года. За это время мы обзавелись большим количеством внешних пользователей — международных и российских. При этом и количество внутренних пользователей подросло: в Городских сервисах Яндекса появились стни новых сервисов на userver. Функциональность Такси, Еды, Лавки, Доставки, а также Маркета, Финтеха, Фантеха, Электро и Техплатформы обогатилась новыми возможностями и новыми пользователями. А значит, фреймворк стал ещё надёжнее и оттестированнее.

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

Почему даже в 2026 году невозможно написать серьезное приложение на Qt, используя исключительно умные указатели? Давайте разберемся, где «умный» код ломает логику фреймворка.

Ценность квалифицированного программиста смещается в сторону умения проводить обзоры кода. Генерировать код становится проще, но всё так же важно проверять его с точки зрения качества декомпозиции, корректности реализации, эффективности, безопасности. Посмотрим на примере маленького проекта markus, созданного с помощью Claude Opus, почему важно понимать сгенерированный код и уметь видеть, что скрывает красивый текст программы.

Утро: 3,8 ТБ памяти на кластеры Prometheus. Вечер: 0,6 ТБ. Между ними — переход на Deckhouse Prom++.

Мы потратили месяцы на внимательный анализ данных и разработку: писали свои структуры данных на С++, экономя каждый байт и охотясь за каждой наносекундой производительности. Разнообразные энкодеры для специфических данных, вектор с дырками и упакованные структуры — в статье делимся деталями реализации Open Source-проекта, который вы можете уже сейчас использовать для реальной экономии на мониторинге.

Если сделать скриншот Netflix или окна воспроизведения в Spotify, на месте видео окажется чёрный прямоугольник. То же произойдёт при демонстрации экрана в Zoom, в записи через OBS и даже в Snipping Tool. Звук идёт, содержимого нет.

Это не защита кодека и не трюк с OpenGL-поверхностями. Это один флаг в одном API, который сообщает оконной системе: «это окно не должно попадать в захваченные кадры». Флаг публичный, документированный, появился в Windows 10 ещё в 2020 году и используется любым приложением, которому нужно закрыть содержимое от скриншотов: менеджерами паролей, банковскими клиентами, 2FA-токенами.

На macOS раньше был симметричный аналог, но в macOS 15 Sequoia Apple сломала его против ScreenCaptureKit, и теперь картина там сильно запутаннее. На Linux всё зависит от дисплейного сервера. В браузерах работает через цепочку платформенных API.

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

Давным-давно, когда Рунет только появлялся, морфологические анализаторы и системы контроля орфографии уже производили вау-эффект: они не только сводили разные словоформы к основной (словарной), но и зачастую умели их склонять/спрягать, описывали грамматику вхождений и предлагали варианты замены ошибочных начертаний. Да и чуть позже, при появлении первого русского морфологического поиска в Интернет – это был Апорт! – на выставках тоже равнодушных не было. Тогда и родился libmorph.

Это продолжение темы начатой в статье Важны ли компилятору имена, и продолженой в Ночью все кошки серы, а using'и одинаковы, и если вам нужна полная картина, как компилятор превращает текст в программу, то без понимания поиска имён (name lookup) дальше двигаться уже не получится.

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

C++ в этом месте особенно коварен. Язык рос десятилетиями, и правила поиска имён эволюционировали вместе с ним: добавлялись пространства имён, шаблоны, ADL, двухфазный поиск. Всё это не просто усложнило модель, оно сделало её местами неинтуитивной даже для опытных разработчиков, добавим сюда еще, что разные компиляторы исторически реализовывали эти правила (по-своему) по-разному, и часть этих различий до сих пор всплывает в коде.

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

Многие наверняка сталкивались с проблемой: смотришь по ТВ спокойный фильм, который прерывается резкой и громкой рекламой; или, например, при общении по ВКС всех собеседников слышно нормально, но у кого-нибудь одного микрофон будет шуметь так, будто он в данный момент находится рядом с двигателем самолета, готовящегося взлетать. Конечно, всегда можно подрегулировать громкость динамиков, но всегда ли это удобно и возможно?

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

Но кажется, что комитет выбрал для C++ совсем другой сценарий развития. Свидетельством чему является включение в стандарт такой странной (на мой деревенский взгляд) штуки, как модули. Раз модули в язык добавили несмотря на то, что это делит и сам язык, и его экосистему, на “до и после” на долгие годы, а то и десятилетия, значит люди из комитета верят, что у C++ эти самые десятилетия бодрого развития и широкого применения есть.

OK, допустим, что цель в том, чтобы C++ счастливо и успешно прожил еще 40 лет, постоянно развиваясь и адаптируясь к новым условиям. Что для этого нужно сделать сейчас? Важный дисклеймер: на мой сугубо субъективный взгляд.

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

Ни Python, ни PyTorch, ни NumPy, … всего 260 строк кода на чистом C++ достаточно, чтобы обучить, оценить и протестировать простой двоичный классификатор, различающий рукописные цифры 0 и 1.

Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен.

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

Всем привет, это моя первая статья, в рамках которой захотелось поделиться необычным для меня опытом. Возможно, кто-то найдёт здесь для себя что-то полезное. По работе пришлось столкнуться с крайне необычной микросхемой для коммутации высокочастотных (RF) сигналов.  Одна проблема – проприетарный интерфейс управления MIPI RFFE. Появился вопрос “А как этим управлять, не имея специализированных средств?”. Ответ узнаем вместе.

У многих из нас есть слабость к маленьким многофункциональным гаджетам. К тем самым коробочкам с мигающими светодиодами, которые покупаются под лозунгом «ну это же мне очень надо!», а потом укоризненно смотрят на тебя с полки. У меня к этой категории относятся «тамагочи для хакеров» Flipper Zero и оранжевый свисток M5StickC Plus2.

С «Флиппером» всё понятно: для классических хакерских шалостей (открывать шлагбаумы и пугать соседей) я его не использую, пару раз клонировал ключи от подъезда да дублировал пропуск на работе. Для меня это стильные настольные часы, токен для аутентификации и крошечная панель мониторинга (я переписал под себя приложение для мониторинга ПК, чтобы выводить на экран загрузку процессора, ОЗУ, видеокарты, состояние сети и прочие метрики).

С M5StickC Plus2 история похожая. Он был куплен по той же причине, по которой айтишники покупают седьмую механическую клавиатуру: потому что штука прикольная. Я покрутил разные прошивки, поигрался с Bruce — швейцарским ножом для устройств M5 — и даже попытался сделать из него такой же экранчик мониторинга, но в отличие от Флиппера, заряда которого хватает на пару дней приёма метрик с ПК через BLE, стик садится почти моментально, да и его экран ощутимо меньше. А потом он предсказуемо перешёл в режим ждуна: лёг на стол и стал ждать своего часа.

Существуют решения для анонимного взаимодействия в интернет пространстве, такие как Tor, I2P и Freenet, но они ориентированы на весь интернет и избыточны для простого общения. Их сложность и архитектура могут быть неудобны в условиях ограниченного доступа к сети. Поэтому возникает идея более простой и специализированной системы. XXCore — это лёгкая p2p-архитектура с доверенными узлами, построенная на PipeNet и модифицированном SSU2.

Когда логирование попадает в реальную систему, довольно быстро становится понятно, что это не про API и не про удобство вызова. Это про постоянный компромисс.

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

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

Естественное желание — привязать лог не к месту вызова, а к самой задаче. Самый прямой путь — передавать контекст через параметры (например, инстанс логгера), но довольно быстро это начинает протекать через весь код и превращается в обязательный шум в сигнатурах. Гораздо более устойчивый подход — привязать контекст к потоку выполнения. В библиотеке logme это делается через thread channel:

Бесплатных IDE для разработки микроконтроллеров не так уж много, а их интерфейс, основанный на Eclipse, вызывает у меня только страдания. В итоге разработка превращается в постоянное переключение с VSCode для редактирования кода в CubeIDE для его сборки и отладки.
Но почему бы не собрать все инструменты в VSCode в едином расширении, заодно подогнав автогенерацию проектов под стиль компании/личные предпочтения? Об и будет моя первая статья. Привет, Хабр!

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

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

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

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

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

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

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

Привет, Хабр! Меня зовут Aloncie. Пока в моем окружении часто спорят о том, какой язык программирования учить первым, я решил не выбирать легких путей и закопаться в «кишки» системного программирования.

Мой проект Rwal — это CLI-утилита (с перспективой перехода на GUI) для управления обоями, которая должна одинаково хорошо чувствовать себя в разных окружениях: от KDE и GNOME до Windows. В этой статье я подробно разберу архитектуру проекта, работу с D-Bus, интеграцию со стандартами C++20 и то, как я организовал сборку.

Всё началось на второй паре по системному программированию. Нам дали задачу: написать CLI-утилиту для анализа логов - парсить файл, фильтровать записи по уровню ошибок, считать статистику, выводить красиво в консоль. "Ну понятно", - открыл я vim и началось мое долгое приключение...

Неделя. Две. Утилита называлась logz, она умела читать логи nginx и apache, фильтровать по уровню (DEBUG, INFO, WARN, ERROR), по дате, по IP, выводила топ адресов с наибольшим числом ошибок, рисовала простенький bar-chart прямо в терминале через unicode-символы. Только вот я сидел как-то вечером, запустил wc -l main.c - 3147 строк. И смотрел на это число минуты три с таким лицом - O_O.

Сама утилита работала. Но открывая её осознаешь что - это месиво. Одна функция process_file на 400 строк. Сегфолты раз в неделю. Valgrind как лучший друг. И каждый раз когда надо добавить фичу - сначала полчаса вспоминаешь что вообще происходит в коде.

Потом я случайно прочитал пост про Zig на lobste.rs. Заинтересовался и попробовал. Через месяц у меня была та же утилита, но теперь на 1089 строках, которая работала быстрее и не падала.

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

Прочитал статью Параллелизм с общим состоянием в Rust и обратил внимание, что её общий смысл можно выразить известной фразой: “делай как нужно, а как не нужно, делать не нужно”. Другими словами, это точно такой же совет, какой можно дать разработчику любого другого языка программирования, например С++.

И решил не продолжать дискуссию в комментариях, а написать отдельную статью с кратким описанием фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должно способствовать) массовому переходу с C/C++ на «безопасные» альтернативы. Так как из-за особенностей распределения затрат у разработчика ПО отсутствует экономическая мотивация к полному устранению ошибок, и как следствие - к переходу на использование «безопасных» языков программирования.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. На днях в Кройдоне состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз (как и в прошлый), всё внимание было сосредоточено на C++26 и… теперь он готов! Осталось пройти формальные этапы в вышестоящих инстанциях ISO, и мы получим C++26 который заслужили. В нём будут:

• reflection,

• контракты,

• SIMD,

• линейная алгебра,

• расширенные возможности сonstexpr,

• hardening,

• Hazard Pointer и RCU,

• #embed,

• executors,

• и многие другие полезные вещи.

Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно‑ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками — вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку.

Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С‑функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема — не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение — хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

Если кратко, то цель: компилятор некоторого подмножества языка Си на C++, который работает в compile-time. Компиляция будет происходить в кастомный байт-код для дальнейшего выполнения в ВМ уже в рантайме.

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

Игра «Жизнь» — это простой клеточный автомат, поэтому она должна хорошо поддаваться GPU-ускорению. Правила просты: каждая ячейка в двухмерной сетке или жива, или мертва. На каждом шаге мы подсчитываем живых соседей ячейки (включая диагонали). Если ячейка жива, она остаётся живой, если живы два или три её соседа. В противном случае она умирает. Если клетка мертва, она оживает, если живы ровно три соседа. Из этих простых правил возникает потрясающий объём сложности, о котором написаны подробные статьи.

Для простоты я буду рассматривать только сети N×N и пропущу вычисления на краях. Всё будет работать на Nvidia A40, а бенчмарк производительности я буду проводить при N=2¹⁶. Пока мы будем хранить каждую ячейку в виде 1 байта, поэтому весь массив займёт 4 ГБ.

Весь код выложен в репозитории GitHub.

В ИТ есть странная форма «информационной инерции»: когда фраза однажды удачно легла на реальность, стала цитатой, превратилась в маркер «своего» - и дальше продолжила жить сама по себе. Реальность уехала, практики сменились, инструменты стали другими, экономика разработки перевернулась, а штамп формулировки остался. И особенно охотно её повторяют те, кому нужно писать быстро и убедительно, но нет времени (или компетенции) разбирать в технических деталях.

И проблема не в том, что старые тезисы изначально были бессмысленными. Проблема в том, что их продолжают подавать как вечные законы природы - без даты, без контекста и без поправок на то, что индустрия в корне изменилась.

Например, фразы про “серебряную пулю” и "небезопасный С++ ", которые звучат почти в каждом популярном тексте о разработке и безопасности, и оба часто переворачиваются так, что становятся откровенной неправдой.

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.

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

В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/

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

В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри:

Привет, Хабр! Меня зовут Анастасия Черникова, я занимаюсь разработкой компиляторных технологий и инструментов на базе LLVM в Синтакоре.

Неопределенное поведение (undefined behavior, UB) по-разному выглядит с точки зрения компилятора и разработчика. Для первого оно, как правило, открывает дополнительные возможности для оптимизации. Для программиста же UB может стать проблемой, особенно если оно остается незамеченным и не учитывается при разработке.

В этой статье рассмотрим подход к поиску UB с использованием статического анализа. В качестве примера я использую clang-tidy: сначала разберу, как устроены существующие чекеры и как работают AST matchers, а затем покажу, как расширять их и добавлять собственные проверки, если стандартных возможностей оказывается недостаточно.

ДИСКЛЕЙМЕР:

Автор не призывает к игре с сторонним ПО. Вся информация, приведенная в статье - приведена лишь в образовательных и ознакомительных целях. Информация была взята из открытых источников и ни к чему не призывает.

СОДЕРЖАНИЕ:

MCP выглядит как удобный способ структурировать LLM-приложение, но за это приходится платить. При этом попытки «ускорить систему» через C++, IPC или смену сериализации не всегда дают ожидаемый результат. В статье разбираю, где на самом деле возникает latency и почему архитектура оказывается важнее, чем выбор технологий.

Анимация: генерирует последовательность из 255 высокоточных кадров в формате BMP (frame_000.bmp ... frame_254.bmp) и автоматически компилирует их в видеоролик (файл Mandelbrot.mp4) с частотой 30 кадров в секунду, используя встроенный FFmpeg.

Скачать последнюю версию (Windows и Linux)
В windows это Mandelbrot_windows.exe и ffmpeg.exe
https://github.com/Divetoxx/Mandelbrot-Video/releases
Выше README содержит English и Русский!

FFmpeg - "швейцарский армейский нож" для обработки видео. В 2026 году он остается отраслевым стандартом, поддерживаемым сообществом разработчиков открытого программного обеспечения. От YouTube и Netflix до профессиональных киностудий - все на него полагаются. И да, он совершенно бесплатный.

Ошибки шаблонов в C++ — отдельный жанр: вы ожидаете простой контракт к типу, а получаете десятки строк из глубин STL. Проблема не в компиляторе, а в том, что сами требования к типам в классических шаблонах долгое время оставались неявными. Concepts это меняют: они позволяют формализовать ожидания к типу прямо в коде, сделать перегрузку осмысленной, а ошибки — читаемыми. В этой статье разберём, как работают concepts, зачем они действительно нужны и как использовать их не как «синтаксический сахар», а как инструмент проектирования.

Наверняка многие и не задумываются: а как на самом деле происходит возврат структур и других типов значений из функций? Что происходит под капотом, какие приемы задействует компилятор? В данной статье я постараюсь дать ответы на эти вопросы и сделать это просто и понятно.

cout - плохой отладчик! Как за 30 секунд найти место падения программы? Какие 7 команд GDB нужно знать каждому C++ разработчику? В этой статье я делюсь личным опытом: как я боялся GDB, думал, что это «магия для гуру», а потом понял, что 70% задач решается простыми командами.

Спойлер: главный страх - это неизвестность. А когда знаешь backtrace, break, next, print и info locals, GDB становится лучшим другом. Статья рассчитана на начинающих C++ разработчиков, которые хотят перестать бояться терминала и начать отлаживать системно.