C++ *

Есть вопрос, который тридцать лет считается риторическим: можно ли вообще построить RAD-парадигму на C++? Ответ очевиден - да, иначе не было бы RAD Studio

А есть второй вопрос, который риторическим совершенно не является: можно ли повторить эту парадигму на классическом C++ без проприетарных расширений, без закрытых библиотек, на голом C++17? Вот на него ответ не очевиден. И именно его мы разбираем в статье.

В БКС есть направление прямого доступа к бирже: мы подключаем клиентов к шлюзам Московской биржи, помогаем с роботами и инфраструктурой. Часто разговор начинается с вопроса про FIX (Financial Information eXchange) — и почти всегда за ним стоят разные вещи. Этот текст — ответ, который мы обычно даём клиентам, только подробнее: с маршрутами заявки, требованиями и примером сообщения.

С++20-корутины, миграция акторной системы и KvadraOS — все это было на митапе для разработчиков на «плюсах», который организовали YADRO и C++ Russia. Под катом собрали записи докладов и рассказали о новых проектах для инженеров: экскурсии по инженерному центру и проекту о работе с легаси-кодом.

Личный проект длиной в шесть лет: от школьных скриптов на Python до OpenGL‑рендера с облачностью, климатом и картами звёздных систем. Когда переписывал рендеринг вручную — уходили недели. Когда подключил LLM — два вечера. Рассказываю, как это было, и что при этом чувствуешь.

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

• Чем отличается new expression от operator new
• Что такое placement new, какой у него синтаксис, и выделяет ли он память
• В каких случаях и зачем нам может понадобиться вызывать деструктор вручную
• Когда использовать std::launder
• Почему какие-то типы можно копировать через memcpy, и ими можно сразу пользоваться, а для других это будет UB?
• Что вы реально можете кастить через reinterpret_cast
• Почему стандарт C++ такой запутанный и бесчеловечный

TLDR; Нельзя просто так взять и запихнуть реальную систему сборки в браузер. Но если обойти некоторые тонкие технические и юридические моменты - вполне можно, что мы показываем наглядно. Статья о том, как это сделано, и немного о том, где можно применить.

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

Проблема встаёт в момент, когда человек узнаёт, сколько в реальности нужно собрать, чтобы получить готовый sysroot для, например, QT: объём работы для подготовки сборочной площадки убивает всю выгоду от идеи. Но что если этой работы делать просто… не нужно.

P.S. Да, это Doom в браузере. Опять. А ещё там есть HoMM2. Ссылка на playground в конце статьи, там, в браузере, можно его запустить, и собрать на свой десктоп. И посмотреть другие примеры.

В этой статье пойдет речь о немаловажных особенностях разработки встраиваемого программного обеспечения (далее ВПО) для микроконтроллеров (далее МК) с низким уровнем абстракции аппаратного обеспечения.

Это не полноценный гайд по написанию кода ВПО, которых на просторах интернета сегодня тьма, а лишь нюансы, которые помогут писать хороший код.

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

Привет, Хабр! На связи финалист ICPC и гроссмейстер Codeforces MachineSolution. Также напомню, что я продолжаю рассказывать о своей подготовке и соревнованиях в Telegram-канале Machine Solution. Иногда я также беру учеников на индивидуальные занятия. Если вам понравились мои статьи и хочется прокачаться в спортивном программировании — пишите мне, обсудим.

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

В этой статье я хочу погрузиться (и погрузить читателя) в дебри C++ на примере написания собственной std::function.

Почему std::function? Потому что реализацияstd::function, внезапно, затрагивает большое количество продвинутых техник и нюансов языка, и все они достаточно любопытны для пытливого плюсовика.

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

В сетевой игрe происходит примерно то же самое, но приходится немножечко врать уже не о положении персонажа, а о времени и если coyote time был маленькой ложью о том, где заканчивается платформа, то lag compensation, будет маленькой ложью о том, когда именно существовал игровой мир.

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

range-based for в C++ выглядит безопасным местом, пока в него не попадает временный объект с внутренней ссылкой. Такой код может годами работать в продакшене, а затем начать читать освобождённую память после смены компилятора или настроек сборки. В статье разбирается, как C++23 изменил время жизни временных объектов в таких циклах, почему поддержка стандарта зависит от компилятора и какие проверки помогут найти проблемные места в кодовой базе.

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

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

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

В качестве панацеи предлагают lock-free структуры, но и тут полно ловушек — банальный регулярный вызов ядра SetEvent способен сжечь весь выигрыш от lock-free. Сами алгоритмы lock-free порой тяжеловесны, не всегда предлагают удачный trade-off и даже не всегда уместны. Но что ещё хуже: будучи применёнными без должной тщательности, они могут не только не дать выигрыша, но даже навредить.

В этой статье мы разберём устройство нескольких базовых объектов библиотеки wxl и познакомимся с концепцией «алгоритм дешевеет под нагрузкой». Мы пройдём путь от трёх базовых инструкций процессора до готового канала, разберём, как продление release-последовательности спасает от ABA, как ленивые триггеры arm/disarm позволяют будить поток только тогда, когда он реально спит, и как заставить данные летать между ядрами без обращений к операционной системе.

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

Как менялась эксплуатация переполнений буфера в Windows за последние десятилетия?

Рассмотрим путь от классического Stack Smashing до современных механизмов защиты потока выполнения. На практике рассматриваются x86-техники переписывания EIP, NOP-sled, JMP ESP, эксплуатация SEH, переход к ROP как способу обхода DEP.

Практически продемонстрированы примеры создания и эксплуатации указанных уязвимостей.

Сколько на самом деле стоит путь пакета через ядро Linux, и сколько из этой стоимости снимают io_uring, AF_XDP и DPDK? Собрал библиотеку, в которой один и тот же цикл отправки и приёма работает поверх семи разных путей, и прогнал её на двух очень разных стендах: на домашнем десктопе с двумя 10-гигабитными портами сетевой карты Intel 82599, соединёнными AOC-кабелем, и на паре инстансов AWS c6in.4xlarge.

Недавно я гонял бенчмарки на свежей сборке CPython (ветка с tail-call интерпретатором, PGO + LTO, GCC) и снял флеймграф стандартного бенчмарка async_generators из набора pyperformance (рекурсивный обход дерева на 100 000 нод с глубиной вложенности ~17).

Картина на профиле оказалась фееричной: почти треть всего процессорного времени (29%) сжиралась кодом, который вообще не делал никакой полезной работы.

Рантайм создавал, настраивал, а затем тут же уничтожал объекты исключений StopIteration, о существовании которых Python-код даже не догадывался.

Ниже о том, откуда растут ноги у этой проблемы в Си-коде CPython и как пара правок в genobject.c дали ускорение в 1.33x — 1.53x.

При написании одного парсинга, в цикле которого создается std::string заметил одну странность, что при определенных ключах цикл работает заметно дольше. Оказалось, дело в инициализации std::string. Написал на это дело бенчмарк.

В экосистемах со сложившейся моделью пакетных индексов вроде Python, Java или JavaScript состав проекта обычно начинают анализировать с манифеста, где разработчик перечисляет прямые зависимости проекта и их допустимые версии. Менеджер пакетов читает эти требования, выбирает совместимые версии и подтягивает зависимости, которые нужны самим пакетам. Конкретный результат выбора сохраняется в lock-файле, где фиксируется уже не диапазон, а точные версии прямых и транзитивных зависимостей. В результате получается список всех пакетов, необходимых для работы с проектом.

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

На крупной кодовой базе это быстро становится проблемой. Например, в нашем разборе автоматизации SBOM для LibreOffice в проекте была сотня с лишним C/C++ библиотек, собственная сборочная система и ресурсы вроде шрифтов и словарей, которые тоже попадают в поставку. За каждым компонентом такого SBOM стоит отдельное расследование от файла и команды сборки к имени проекта, версии и источнику. На каждом переходе теряется своя часть данных.

В CodeScoring мы анализируем состав программных продуктов и на практике часто сталкиваемся с ограничениями разных экосистем. Разбор проектов на C/C++ требует особого внимания. В этой статье мы разобрали особенности этой экосистемы, которые осложняют построение SBOM, и постарались рассказать, что позволяют выяснить разные методы анализа.