C++ *

Rust + LLM: новая и сильная “ОПГ” против C++ и его друзей…

Есть такая штука с Borrow Checker - он ненавидит людей. Не потому, что он плохой, а потому, что требует держать в голове графы данных всего приложения всё время, пока пишешь. Люди устают, раздражаются, и в итоге - unsafe, чувство стыда перед собой и коллегами, и понеслась. А LLM на это просто… скажем, кхм, “не важно”. Ну, надо так надо. LLM итерирует. И самое забавное - ей можно запретить unsafe прямо в промпте, и она не будет искать обходные пути(ну, может, разок другой - Opus попробует, но это ловится простым поиском по файлам, даже PVS-Studio не нужен, хотя с ним было бы фееричнее). Скорее всего, LLM просто найдёт решение в рамках safe Rust. И это круто.

Про Python и JS - там ведь основная проблема не скорость даже(и синтаксически значимые пробелы у некоторых), а то, что деплоится не программа, а среда. Интерпретатор, зависимости, версии, “а на проде другой питон”… Сейчас с линковщиком от Zig можно прямо из Windows собрать бинарник под Linux - статически, без танцев(привет musl!), одним пинком. И это не какой-то хак, это просто работает. Получаешь один файл, который либо запустится, либо нет - без сюрпризов в середине.

C++ тут проигрывает не потому, что он сложный или плохой - он интересный, мощный, с огромной историей и экосистемой. Но именно эта мощность становится проблемой когда код - генерирует LLM(можно выстрелить себе в ногу из гранатомёта, и, самое страшное - не заметить этого). Модель получает слишком много способов сделать что-то, и часть из них - UB. Rust убивает целый класс таких подходов к реализации на уровне компилятора. Это не договорённость и не линтер - это просто не скомпилируется.

Мне кажется, уникальность этой связки тут в том, что задачи разделились очень чисто: LLM думает про логику, компилятор думает про корректность. И они не мешают друг другу. В C++ - см. выше. Именно то, что делает Rust тяжёлым для людей(кроме евангелистов и стримеров), делает его почти идеальным для этой связки.

Ну и если кто был травмирован неудачным опытом с “вайб-кодингом”, и сложилось впечатление, что вся эта пляска с LLM, это не серьёзно - попробуйте отложить китайщину(MiniMax, GLM, DeepSeek...), взять фронтир-модель типа “OpenAI Codex GPT-5.5 на XtraHigh” - и дать ей хотелку в виде описания какого-нибудь серверного приложения на Rust, и просто посмотреть что будет через 15-20 минут. Забейте на клоунов со “змейкой” и прочей мелочёвкой из бенчмарков на ютубе, попробуйте реальную задачку(многохопывый релей между серверами со своим протоколом КВН например и клиентами для Win/Linux). Оно сделает. Быстро. Качественно. Это довольно странное ощущение, честно говоря, видеть такое…

Просто мысли вслух, хотелось поделиться)

-s. TekMetrics certified “Master C programmer”, July 1999

Тихий враг или молчаливый союзник? Коротко о выравнивании в C++. Часть 3

Мы уже разобрали базовое выравнивание полей и изучили, как наследование наслаивает данные друг на друга. Казалось бы, теперь-то всё — все ловушки изучены. Но не тут-то было! Есть у этой темы ещё одна, по-настоящему тёмная сторона, про которую не так часто говорят.

Одно короткое слово virtual полностью переписывает "геометрию" класса, внося в выравнивание свои коррективы, которые трудно игнорировать. Давайте разберёмся, что на самом деле происходит под капотом, когда выравнивание сталкивается с виртуальностью.

Чернобыльское лето 1986 года, когда все киевские одноклассники разъехались по разным концам СССР подальше от радиации, было для меня супер-продуктивным в смысле изучения программирования. Я ходил в контору человека по фамилии Долина, бывшего полковника танковых войск из Донецка, который переквалифицировался в компьтеризатора украинского образования. Там я работал на компьютерах MSX Yamaha, выучил программирование на Си. Компилятор назывался ASCII C (сейчас в комментах появятся умники которые будут мне говорить, что ASCII это кодировка, а я им буду кидать ссылку что это еще и японская компания).

Долине мое увлечение Си не нравилось, он хотел чтобы я больше писал программ на Бейсике, которые он демонстрировал людям из украинских министерств и студии мультфильмов (некоторые программы были графические). Кроме графики я сделал еще например программу которая фиксировала в реальном времени действия футболистов во время матча, через нажатия клавиш наблюдателем. Контора Долины была у стадиона, оттуда доносились вопли болельщиков. Долина это показывал кому-то по спортивной линии.

В конце лета я полетел на Новосибирскую Летнюю Школу Юных Программистов, где выучил ассемблер Z80 и сделал поддержку параллельного выполнения нескольких Си функций с помощью переключения контекстов в обработчике прерывания по таймеру. С сохранением регистров в дексрипторе задачи в списке задач. За это я получил диплом первой степени. По-моему дипломы вручал академик Ершов, хотя может я путаю и мы встретились с ним в академгородке куда на тоже возили.

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

Еще там я увидел первые советские программы западного качества - редактор tor(?), программу низкоуровневой работы с диском и оконный отладчик. Они были написаны на Си и ассемблере аккуратно, как примеры в западных книжках. Советский код который я видел до этого (и большинство после этого) был написан тяп-ляп. Писали эти программы местные аспиранты которые были также преподавателями школы.

Помимо этих программ я привез на флоппи-дисках со школы CP/M (хуже файловая система чем в MSX-DOS), среду Turbo Pascal, интерпретатор Lisp, компилятор Nevada Fortran, еще два компилятора Си (Aztec C и BDS C) и даже компилятор с подмножества языка Ada, который я знал теоретически, но никогда не использовал.

29 лет спустя, в 2017 году я приехал на ту же новосибирскую школу в качестве инструктора по Verilog и FPGA. Еще там был Борис Файфель который учил детей Лиспу или чему-то такому.

Оптимизация контекста для Claude Code на большом проекте (иногда и 50% экономия токенов)

Работаю над большим C++ проектом - реализация сетевого протокола. Использую Claude Code как основной инструмент. Со временем заметил: каждый новый чат начинается с того, что агент долго читает README.md, который разросся до 1000+ строк и 60 КБ.

Проблема

В CLAUDE.md была прописана команда читать README.md в начале каждого диалога, агенту нужно дать контекст проекта. Пока проект был небольшим это работало нормально. Но README рос вместе с проектом и в итоге стал содержать всё: архитектуру, логику DTLS, настройки веб-интерфейса, описание протокола, инструкции по сборке.

И как результат:

• Агент тратит тысячи токенов на анализ файла до начала работы

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

Решение

Вместо одного большого файла использовать иерархию маленьких, в отдельной папке claude-context/:

claude-context/
├── context-claude.md       # общая архитектура и навигация (~90 строк)
├── context-AC-claude.md    # Access Controller
├── context-WTP-claude.md   # WTP Agent
├── context-WEB-claude.md   # Web Interface
└── context-TESTS-claude.md # тесты

Главный файл context-claude.md содержит краткое описание проекта и таблицу-навигатор: какой файл читать для какой области. В дочерних файлах описана детализация по модулям, каждый 100-130 строк.

Инструкция в CLAUDE.md теперь выглядит так:

“Start each new conversation by reading claude-context/context-claude.md. For deeper context on specific areas, read the relevant file from that directory.”

Агент читает главный файл (90 строк), понимает область задачи, подгружает только нужный дочерний контекст.

Замер

Чтобы проверить эффект, я поставил Claude одну и ту же задачу в двух разных конфигурациях:

“Добавь тесты для WtpConfigController и WtpRadioController, проверь что если WTP address не строка, то возникает исключение std::runtime_error”

| Параметр             | README.md (60 КБ) | Иерархический контекст | Разница  |
| :------------------- | :---------------- | :--------------------- | :------- |
| Токены на сообщения  | 36.8k             | 17.6k                  | -53%     |
| Всего токенов        | 56.7k             | 37.6k                  | -34%     |
| Рост usage за задачу | +11%              | +6%                    | В 2 раза |
| Скорость анализа     | Заметная пауза    | Почти мгновенный старт |          |

Важный момент

README.md остался нетронутым - это документация для людей. Файлы в claude-context/ - отдельный артефакт, написанный под AI: плотно, без лирики, с ASCII-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

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

🌲 Открываем регистрацию на Дебаг Кемп

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

📅 6–7 июня 2026 (выходные) 👥 Всего 25 мест — маленький формат, это принципиально.

Цена растёт по мере приближения к дате. Оплатить можно частями через сплит → регистрация

Если вы 💎 практик сообщества — скидка 15% применяется при регистрации автоматически. Ещё не практик, но думаете? Сейчас самый разумный момент.

👀 Узнать больше · 📝 Регистрация

Вопросы — в чат, мы там живём.

Тема неопределённого поведения (UB) в языке C++ освещается и обсуждается многие годы, но это не значит, что она исчерпала себя. Это плата, которую программисты отдают за эффективные оптимизации кода, такие как удаление ряда проверок.

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

Полезные ссылки из доклада:

• Undefined behavior ближе, чем вы думаете

• Ложные представления программистов о неопределённом поведении

• Подножка для AI в виде UTF-8

• Путеводитель C++ программиста по неопределённому поведению

Примечание. Был задан вопрос про безопасные компиляторы (ГОСТ Р 71206—2024). Подробнее с этой темой можно познакомиться здесь: Использование безопасной системы сборки программного обеспечения

Сделайте свой проект чистым с PVS-Studio. Месяц бесплатного использования по промокоду.

Переосмысление библиотеки LDL.

Я полностью пересмотрел концепцию библиотеки LDL.

Что такое LDL?
Это графическая библиотека с единым API для всех систем как старых, так и новых.

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

Новая стратегия

Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.

• Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.

• Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.

• С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.

Лицензия и целевые платформы

• Лицензия меняется на LGPLv3.

• На старте поддерживаются Windows и Linux.

Качество и инструменты

При разработке использую:

• AddressSanitizer (ASan)

• UndefinedBehaviorSanitizer (UBSan)

• Различные анализаторы кода

Я считаю, что такая стратегия полезнее, чем годами доводить библиотеку до версии 1.0 в офлайн-режиме.

Примеры и бэкенды

• Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.

• Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.

• API остаётся единым для всех бэкендов.

Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.

 2D-рендер без границ

Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.

Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).

• Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.

• Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.

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

Философия: Машина времени в вашем коде

Зачем тратить силы на поддержку систем, которые многие считают «трупами»?

1. Борьба с цифровым забвением

Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.

2. Инженерный аскетизм

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

3. Преемственность поколений

Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.

Итог

LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.

Один API. Один код. Тридцать лет компьютерной истории.

Всё, что нужно знать для начала работы в PVS-Studio

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

Сравнивал разные методы сделать call-once (а точнее инициализацию синглтона) - далее небольшие заметки.

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

1. статичный глобальный объект, вычисление вызывается в конструкторе

2. статичный глобальный объект + std::call_once

3. статичный локальный объект в функции, вычисление вызывается в конструкторе

Чтобы в годболте видеть что и где вызывается - определяем тип имеющий только объявления методов (это заставит компилятор ставить явный call)

struct TSomeExternal {
    TSomeExternal(int);
    ~TSomeExternal();

    int DoCalc();
    char Data[60]; // просто чтобы было проще увидеть
};

Особенности первого варианта:

• вычисление "до main"

• неконтролируемый порядок инициализации глобальных ответов => нельзя иметь зависимости между такими объектами

• вычисление только в рамках 1 потока

• уникальный плюс: нет проверок "на горячем цикле" - при обращении к объекту вызывающая функция может считать что данные уже готовы (но именно этот плюс стоит нам второго пункта)

В годболте можно посмотреть на func1 - видно что она скомпилилась просто в забор поинтера, и call

TSomeExternal GlobalValue(7);
int func1() {
    int x = GlobalValue.DoCalc();
    return x + 14;
}

Также видно что были порождены - указание что нужно разместить объект

GlobalValue:
        .zero   60

А также _GLOBAL__sub_I_example.cpp - там видно, что вызывается конструктор, и регистрируется указатель на деструктор в пост-колбеках (__cxa_atexit)

Второй вариант (более правдоподобно было бы внести call_once внутрь глобального объекта, но для простоты сравнения сделал как ниже)

static std::once_flag flag;
static std::unique_ptr<TSomeExternal> ptr;
void init() {ptr = std::make_unique<TSomeExternal>(7);}

int func2() {
    std::call_once(flag, init);
    int x = ptr->DoCalc();
    return x + 14;
}

• настоящая инициализация случается только в момент первого использования (ленивая инициализация). Это может быть как плюс (позволяет не тратиться на инициализацию если данные не будут использоваться), так и минус (первые запросы/итерации будут медленными)

• разные инициализаторы данных вполне могут работать одновременно из разных потоков

• имхо - дорогой основной цикл (очень много инструкций до TSomeExternal::DoCalc) - это всё подготовка вызова call pthread_once, который будет выполнен каждый раз

Третий вариант годболт

int func3() {
    static TSomeExternal prepared = {7};
    int x = prepared.DoCalc();
    return x + 14;
}

• в рантайме есть проверка - но это проверка и так нужного нам указателя на null

push    rbx
movzx   eax, byte ptr [rip + guard variable for func3()::prepared]
test    al, al
je      .LBB0_1

• если указатель не нулевой, то переход не будет выполнен и мы сразу переходим к

        lea     rdi, [rip + func3()::prepared]
        call    TSomeExternal::DoCalc()@PLT

• в случае если указатель не готов, то подготовка случается под блокировкой (__cxa_guard_acquire)

• конкретно в годболте не видно, но создаются слоты для guard variable for func3()::prepared и func3()::prepared (в этом смысле разницы со вторым вариантом мало)

Итого: ленивое вычисление, также возможна многопоточная инициализация, а также дешёвый success-path

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

NixOS: идея, до которой индустрия доросла только сейчас.

Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.

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

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

Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.

😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.

Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.

А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.

📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.

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

Зарегистрироваться тут

🚀 Бесплатный курс для разработчиков: создаём свой язык программирования!

Приглашаем вас пройти наш курс и разобраться, как устроены языки программирования изнутри.

Изначально курс делали для прохождения внутри компании, но решили, что полезного материала так много, что хочется рассказать всему миру!

Этот курс подойдёт разработчикам, которые хотят выйти за рамки повседневной разработки и глубже понять фундаментальные принципы работы кода. Да, примеры будут на C++, но сам материал гораздо шире и будет полезен программистам с любым стеком. Независимо от того, пишете вы на C++, C#, Java или любом другом языке, понимание внутренней архитектуры языков сделает вас сильнее как инженера.

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

Вы увидите, как текст программы превращается в структуру, понятную машине, и поймёте, какие решения стоят за этим процессом.

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

Мы постарались сделать материал одновременно понятным и практико-ориентированным: минимум абстракции ради абстракции — максимум смысла.

Если вы хотите лучше понимать, что происходит "под капотом" программирования и прокачать инженерное мышление — этот курс для вас.

👉 Подробности и доступ к курсу по ссылке.

Присоединяйтесь и изучайте программирование глубже — бесплатно!

Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....

Как далеко видит lookup в C++?

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

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

Приветствую, Хабравчане!

Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?

У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.

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

На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?

Запасной вариант, если основному ПК не хватит инструкций.

В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.

На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.

Что планирую потестить:

1. C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.

2. Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).

3. C++: Сравнить скорость сборки проекта с модулями и без них.

4. Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.

5. IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.

Прошу совета у сообщества: накидайте идей! Какие бенчмарки прогнать? Какой софт или специфические проекты попробовать собрать, чтобы нащупать предел возможностей?

Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!

Update: Поправил текст, ошибки и очепятки.

Тихий враг или молчаливый союзник: коротко о выравнивании в C++. Часть 2

Казалось бы, тайна выравнивания раскрыта. Вы победили невидимого врага — невыровненный доступ. Память под контролем, но производительность по-прежнему шепчет: "Есть ещё нюансы". Что? Нюансы? Какие? Пришло время посмотреть, что происходит, когда структуры начинают наследовать друг друга. Здесь всё становится... интереснее. Правила игры меняются.

Итак, путь ясен: мы погружаемся в мир наследования, чтобы услышать его диалог с памятью. Давайте сразу к делу. Приготовьтесь, правила только что усложнились. В статье поговорим о выравнивании, наследовании POD-структур и множественном наследовании.

Исключения — самый коварный механизм C++. Код компилируется, тесты проходят, но в продакшне система падает из-за partially constructed object или утечки в деструкторе. Результат — часовой дебагг и нестабильность.

Основная ошибка: путаница между Basic и Strong guarantee. «Валидный» объект ≠ «корректный». Вы нарушаете инварианты, даже не подозревая об этом.

На вебинаре «Exception Safety в C++: как писать код, который не ломается» развенчаем мифы об Exception Safety. Не теория, а разбор реальных антипаттернов из кодовых баз:

➕ Исключения в деструкторах и как RAII решает это.

➕ Где noexcept ломает гарантии, а где — критически важен.

➕ Move-семантика и её скрытые опасности.

‼️Вы получите: чёткую ментальную модель и чек-лист для код-ревью, который можно применять уже на следующий день.

📅 Дата: 5 февраля

⏰ Время: 17:00-18:00 (Мск)

👨‍🎓 Спикер: Козырев Дмитрий — специалист в области разработки на C++.

➡️ Регистрация ⬅️

Тихий враг или молчаливый союзник: коротко о выравнивании в C++

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

Предлагаю вам вместе попробовать разобраться в такой непростой теме в этой статье.

Что нового появилось в PVS-Studio в 2025 году

Новый 2026 год уже вовсю идёт, и мы решили оглянуться назад и вспомнить, что интересного появилось в PVS-Studio за богатый на изменения 2025 год:

• десятки новых диагностических правил, включая проверки, ориентированные на безопасность;

• обновления интеграций в популярные IDE, CI/CD-системы, ASOC и сборочные системы;

• улучшения анализа;

• расширенная поддержка стандартов.

Всё это и многое другое описано в новой статье в нашем блоге.

Надоело искать парные вкладки (.h/.cpp) в VS Code? Я навайбкодил расширение, которое их магнитит.

Привет! Меня всегда немного раздражала одна мелочь в VS Code.

Открываешь Source.cpp, хочешь посмотреть заголовок, а Source.h открыт где-то в конце списка вкладок или вообще затерялся среди десятка других файлов. Приходится глазами искать его или тянуться к дереву проекта.

Стандартные методы сортировки тут не помогают, поэтому я написал Tab Magnet.

Как это работает:
Вы просто кликаете на файл в Explorer-е. Tab Magnet проверяет, открыта ли его "пара" (например, .h для .c или .html для .component.ts), и если да - автоматически переносит её поближе, чтобы они стояли бок о бок.

Функционал:

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

• Поддерживает из коробки C/C++, C#, Web (JS/TS/HTML/CSS) и Angular.

• Можно настроить свои правила (например, для Go тестов или специфичных структур папок).

vscode marketplace: Tab Magnet

GitHub: tab-magnet

Я подумал, что было бы интересно сделать дотошное исследование кода, который обеспечивает функционирование исключений в С++, и написать статью об этом. Разные платформы могут реализовывать исключения по-разному, поэтому показалось логичным сконцентрироваться на мире Linux.

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

Всё рассмотрение строится на конкретном примере. Где возможно, опираюсь на библиотеку libcxx от LLVM, а в остальных случаях — на libstdc++ от GCC.

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