C++ Academy

⚡️ Почему RSA в OpenSSL не делает «обычное деление» В реализации RSA внутри OpenSSL почти не используется прямое модульное деление. Вместо этого там работает Montgomery reduction - алгоритм, который ещё в 1985 году предложил Питер Монтгомери. Идея простая: в RSA постоянно нужны операции вида «умножили большие числа и взяли остаток по модулю». Обычное деление на больших числах дорогое, поэтому его стараются избегать. Montgomery reduction переводит вычисления в специальную форму, где параметр R выбирают как степень двойки. После этого часть дорогих делений превращается в сдвиги битов и более дешёвую арифметику. Для пользователя это незаметная деталь. Но без таких трюков современный RSA был бы намного медленнее. Есть хороший шанс, что HTTPS-соединение, которым вы пользуетесь прямо сейчас, где-то внутри уже опиралось на эту технику.

🎯 Продвинутое использование отладчика GDB Приглашаем на открытый урок. 🗓 08 июля в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «Системное программирование». Программа урока: ✔️Кратко вспомним базовое использование GDB; ✔️Написание сценариев GDB; ✔️Условные точки останова и точки наблюдения; ✔️Дампы памяти и отладка по сети. После занятия вы будете знать: • Как отлаживать программы на другой машине; • Как использовать возможности автоматизации отладчика для поимки плавающих багов; • Как отладчик работает "под капотом".; 🔗 Ссылка на регистрацию: https://otus.pw/vKKX/?erid=2W5zFJLXK5K Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

В C++20 у std::atomic появились wait() и notify_one(). Это удобная штука для случаев, когда поток должен просто дождаться изменения атомарного значения без mutex, condition_variable и ручного busy waiting. Раньше для такого обычно оборачивали OS-level примитивы вроде futex или pthread_cond. Теперь можно писать прямо так:

#include <atomic>
#include <thread>

std::atomic<bool> ready{false};

void waiter() {
    ready.wait(false, std::memory_order_acquire);
}

void notifier() {
    ready.store(true, std::memory_order_release);
    ready.notify_one();
}

Что здесь происходит: wait(false) блокирует поток, пока ready остаётся false. Другой поток делает store(true) и будит ожидающего через notify_one(). Главное отличие от обычного цикла проверки - поток не крутится впустую и не жрёт CPU. Это не полная замена condition_variable. Для сложных predicates, очередей и нескольких условий condition_variable всё ещё нужен. Но для простого флага, состояния или lightweight-синхронизации std::atomic::wait часто даёт более чистый и быстрый код. C++20 тихо добавил одну из самых полезных низкоуровневых фич для concurrent programming.

🚀 Библиотека ycetl для C++20: constexpr на первом месте ycetl — это заголовочная библиотека, обеспечивающая контейнеры и умные указатели, работающие как во время компиляции, так и во время выполнения. Она предназначена для создания сложных структур данных с использованием механизма памяти, который поддерживает многотипные операции. 🚀 Основные моменты: - Контейнеры, работающие в constexpr и на этапе выполнения. - Умные указатели с поддержкой различных схем владения. - Многотипная память для безопасного управления типами. - Примеры использования, включая компиляцию простых чисел и вложенных деревьев. - Совместимость с C++20 и современными компиляторами. 📌 GitHub: https://github.com/zokrezyl/ycetl #cpp

ИИ меняет не только разработку, но и дата-центры. Когда говорят о развитии ИИ, обычно обсуждают новые модели и алгоритмы. Но по мере роста вычислительных нагрузок ограничения всё чаще возникают на уровне инфраструктуры. На infra.conf’26 Яндекс объявили, как перестраивает физическую и ML-инфраструктуру компании под новые требования. Что меняется: - компания переходит к концепции кампусов дата-центров мощностью до 180 МВт; - внедряет жидкостное охлаждение для более эффективного отвода тепла и снижения энергопотребления; - развивает внутренний сервис Dev Cluster, который ускоряет проведение ML-экспериментов и сокращает время разработки моделей. Интересно здесь не только увеличение вычислительных мощностей. По мере развития ИИ инфраструктура всё сильнее становится частью продукта. Производительность моделей теперь зависит не только от качества алгоритмов, но и от того, насколько быстро можно предоставить вычислительные ресурсы, отвести тепло и масштабировать эксперименты.

✔️ Компилятор C однажды «опроверг» теорему Ферма Теорема Ферма говорит: не существует целых чисел, для которых выполняется: `a³ + b³ = c³` Её доказал Эндрю Уайлс в 1995 году - спустя 358 лет после формулировки. Но затем Джон Регер показал забавный пример: цикл, скомпилированный через gcc -O2, мог напечатать: Fermat's Last Theorem has been disproved В коде происходило signed integer overflow - переполнение знакового int. А в C это undefined behavior. Для компилятора это значит: «такого не должно происходить». Поэтому оптимизатор имеет право строить предположения, которые человеку кажутся абсурдными. В итоге: программа выглядит так, будто нашла контрпример к великой теореме, хотя на деле просто попала в UB. C не опроверг Ферма. C просто напомнил, что undefined behavior - это не ошибка выполнения, а разрешение компилятору делать почти всё что угодно.

Quake сегодня исполнилось 30 лет. 🎉 Спустя три десятилетия всё ещё актуален интересен исходный код игры, которая помогла сформировать современные игровые движки, мультиплеерные сетевые технологии и культуру моддинга. 🎮 GitHub: github.com/id-software/quake

🚀 CPrime: Новый язык программирования на основе C и C++ CPrime сочетает в себе скорость компиляции C и выразительность C++, минимизируя сложности последнего. Этот язык позволяет компилировать C-программы и многие C++ файлы, предлагая при этом удобные инструменты для структурирования кода. 🚀 Основные моменты: - Высокая скорость компиляции, сопоставимая с C - Поддержка объектно-ориентированного программирования - Простота использования и совместимость с C - Минимизация лишних сложностей C++ - Быстрая разработка и активное тестирование 📌 GitHub: https://github.com/LukeSchoen/CPrime

🗺️ Полный роадмап C++ 2026 — от нуля до профессионала Это не просто список тем, а пошаговый маршрут превращения новичка в профессионального C++-разработчика. Каждый уровень даёт не только перечень концепций, но и рабочие примеры кода с пояснениями «как правильно» и «как неправильно», чтобы вы сразу видели идиоматичный современный C++, а не устаревшие практики из учебников 2000-х годов. Роадмап построен по принципу «теория рядом с практикой»: сначала вы изучаете концепцию на коде из соответствующего уровня, а затем углубляете понимание в разделе. 📚 Теория C++, где каждая тема разобрана от базовой интуиции до тонкостей, важных на собеседованиях и в продакшене. Такой подход экономит месяцы: вы не зубрите оторванные факты, а понимаете, почему язык устроен именно так. Как пользоваться: идите по уровням сверху вниз, не перепрыгивая. Пишите каждый пример руками, ломайте его, смотрите на ошибки компилятора — именно так формируется интуиция. Параллельно решайте задачи на платформах из раздела ресурсов и читайте теорию по мере появления вопросов. https://github.com/justxor/cpproadmap2026/tree/main

☕️ Latte: Ultra-Low Latency C++ Telemetry Framework Latte — это заголовочная библиотека C++ для телеметрии, предназначенная для высокочастотной торговли и реального времени. Она измеряет циклы ЦП с помощью таймеров x86_64 и использует фиксированные кольцевые буферы для хранения данных, минимизируя накладные расходы. 🚀Основные моменты: - Высокая точность измерений в наносекундах. - Поддержка до 64 активных слотов на поток. - Три режима измерений: Fast, Mid и Hard. - Без динамических аллокаций во время работы. - Статистический анализ и очистка данных от выбросов. 📌 GitHub: https://github.com/MoonFlowww/Latte #cpp

На UNIX stdout - это просто файловый дескриптор 1. И из-за этого можно поймать очень неприятный эффект: если закрыть stdout, следующий открытый файл может получить тот же дескриптор 1. То есть код вроде этого:

close(1);
FILE *f = fopen("output.txt", "w");
printf("hello\n");

Может записать printf не в терминал, а прямо в output.txt. Потому что система обычно выдаёт минимальный свободный файловый дескриптор. Закрыл 1 - значит он снова свободен. Открыл файл - он может стать новым stdout. Мелочь, но именно из таких мелочей и состоит настоящее понимание UNIX.

CUDA 13.3 - это не просто очередной апдейт тулкита NVIDIA, а шаг к более высокоуровневому GPU-программированию. Главное изменение - CUDA Tile теперь доступен в C++. Это модель, где разработчик описывает вычисления через тайлы, а низкоуровневые детали вроде параллелизма, перемещения данных, асинхронности и работы с памятью берёт на себя компилятор. Для C++-команд это важно: можно встраивать tile-подход в существующие CUDA-кодовые базы, не переписывая всё вокруг нового DSL. Что ещё добавили: - CUDA Tile C++ для более компактных и переносимых GPU-кернелов - поддержку Hopper с Compute Capability 9.0 - CompileIQ - автонастройку компилятора под конкретные кернелы - CUDA Python 1.0 как стабильную версию Python-интерфейса к CUDA - обновления для checkpointing, IPC и работы с контекстами - улучшения для tensor interoperability Самое интересное здесь не «ещё немного быстрее», а смена уровня абстракции. NVIDIA постепенно двигает CUDA от ручного управления потоками, памятью и синхронизацией к модели, где разработчик описывает вычисления, а компилятор сам ищет эффективный путь к железу. Для AI-инфраструктуры это особенно важно. Кастомные кернелы для attention, GEMM и инференса остаются узким местом, но писать их руками дорого и сложно. CUDA 13.3 делает этот слой доступнее для C++, Python и production-команд, которые хотят выжимать производительность без полного погружения в низкоуровневую CUDA-магию. NVIDIA явно строит не просто GPU, а полный стек: язык, компилятор, runtime, Python-интерфейсы и инструменты автооптимизации. https://developer.nvidia.com/blog/nvidia-cuda-13-3-enhances-gpu-development-with-tile-programming-in-c-compiler-autotuning-and-python-updates

🧩 Эффективный менеджер памяти для C rpmalloc — это кроссплатформенный, безблокировочный и кэшируемый аллокатор памяти, обеспечивающий 16-байтовое выравнивание. Он предлагает высокую производительность и простоту использования, что делает его отличной альтернативой популярным аллокаторам. Поддерживает множество платформ, включая Windows, Linux и macOS. 🚀Основные моменты: - Быстрая работа без лишних накладных расходов. - Легко настраиваемый API для управления памятью. - Поддержка многопоточности с кэшированием. - Публичная лицензия без ограничений на использование. 📌 GitHub: https://github.com/mjansson/rpmalloc #c

C23 был-то добавилен checked integer arithmetic В C долго приходилось руками писать однотипные helper-функции, чтобы безопасно проверять переполнение при сложении, вычитании или умножении. Теперь в C23 для этого появился заголовок:

#include <stdckdint.h>

И функции вроде ckd_mul:

#include <stdckdint.h>
#include <stdint.h>
#include <stdio.h>

int main(void) {
    int32_t price = 500000;
    int32_t qty = 8000;
    int32_t total;

    if (ckd_mul(&total, price, qty)) {
        puts("overflow caught, not shipped");
        return 1;
    }

    printf("total: %d\n", total);
}

Смысл простой: если результат помещается в тип, он записывается в total. Если произошло переполнение, функция возвращает true. Это особенно полезно в коде, где числа приходят извне: • размеры буферов • цены и количества • индексы • длины массивов • расчёт памяти • сетевые пакеты • парсеры бинарных форматов Раньше такие проверки часто писали руками, и там легко ошибиться на границах типа. Теперь стандартная библиотека даёт нормальный способ сказать: «умножь, но не дай мне случайно получить мусор из-за overflow». Маленькое изменение в стандарте, но для системного кода очень приятное.

📊 Минималистичная графовая база данных на C++17 TGDB — это простая графовая база данных, реализованная как статическая библиотека. Она поддерживает фиксированные узлы и индексные указатели, обеспечивая схему без схемы и работу с базовыми типами данных. База данных позволяет эффективно создавать и извлекать объекты с свойствами. 🚀Основные моменты: - Унифицированный тип узла размером 56 байт. - Поддержка встроенных типов: int, double, std::string. - Двусторонние ссылки между узлами. - Дисковая устойчивость через mmap. - Быстрый локальный обход и глобальный поиск. 📌 GitHub: https://github.com/LincolnCox29/TrueGraphDataBase #cpp

Ищем Senior Rendering Engineer (C++) в команду 3D-карты 2ГИС Мы делаем карту более реалистичной: работаем над рельефом, дорогами, развязками, тоннелями, анимациями и графическими эффектами. Внутри — собственный 3D-движок на C+20 (500k строк кода), современные графические API (Vulkan, Metal, OpenGL), шейдеры, сложные алгоритмы и задачи производительности. Будет интересно, если вам нравится компьютерная графика, низкоуровневая разработка и создание продукта, который ежедневно используют миллионы людей. Удалённо из РФ или из офисов 2ГИС. ДМС, обучение, конференции и возможность напрямую влиять на развитие 3D-карты. Подробнее Другие инженерные инсайты от 2ГИС → в Telegram-канале RnD

⚡️ Бинарный поиск, который вы выучили, скорее всего, был неправильным. Джон Бентли опубликовал реализацию бинарного поиска в *Programming Pearls* после того, как доказал её корректность и протестировал. Баг прожил почти 20 лет. Позже Джошуа Блох нашёл точно такую же ошибку в реализации бинарного поиска, которую сам написал для JDK. Исследование 1988 года показало: корректный бинарный поиск был только в 5 из 20 учебников. Ошибка проявляется только на массивах размером 2^30 элементов и больше. Проблема возникает при вычислении середины:

mid = (low + high) / 2;

На очень больших массивах low + high может вызвать переполнение. Правильнее писать так:

mid = low + (high - low) / 2;

В C такое переполнение может привести к выходу за границы массива и непредсказуемому поведению. В Java это обычно заканчивается ArrayIndexOutOfBoundsException. Та же ошибка затрагивала mergesort и огромное количество других алгоритмов «разделяй и властвуй».

🔐 Стань этичным хакером - с нуля до Pro Хочешь зарабатывать на поиске уязвимостей, а не бояться их? Этот курс проведёт тебя от первой команды в терминале до реальных техник пентеста. Что внутри: → Разведка целей: nmap, curl, анализ заголовков → Криптография и разбор кода на практике → Эксплуатация уязвимостей и документирование находок → Только живые задачи — никакой воды Без скучной теории. Только то, за что платят в bug bounty и на собеседованиях в InfoSec. 📈 От «что такое порт» — до отчёта пентестера за несколько недель. 👉 Записывайся на Stepik и начни взламывать легально уже сегодня.

📓 Пять PDF по оптимизации, которые реально стоит сохранить. Жёсткая база по тому, как код превращается в инструкции, как эти инструкции исполняются процессором и почему иногда «очевидно быстрый» вариант внезапно медленнее. Что внутри: 1. Optimizing software in C++ 179 страниц про оптимизацию C++ под Windows, Linux и macOS. Память, ветвления, компиляторы, SIMD, профилирование и типичные ошибки. 2. Optimizing subroutines in assembly language 156 страниц про x86 assembly. Полезно даже если вы не пишете на ассемблере, потому что после этого проще понимать, что делает компилятор. 3. The microarchitecture of Intel, AMD and VIA CPUs 277 страниц про устройство процессоров: pipeline, кеши, предсказание ветвлений, execution units и прочие вещи, которые напрямую влияют на скорость кода. 4. Instruction tables 485 страниц таблиц с latency, throughput и micro-ops для инструкций Intel, AMD и VIA. Это уже не чтение перед сном, а справочник для тех случаев, когда надо понять, где именно теряется производительность. 5. Calling conventions 60 страниц про calling conventions в разных C++ компиляторах и ОС. Пригодится для ABI, FFI, отладки, reverse engineering и низкоуровневого кода. Ссылки: https://agner.org/optimize/optimizing_cpp.pdf https://agner.org/optimize/optimizing_assembly.pdf https://agner.org/optimize/microarchitecture.pdf https://agner.org/optimize/instruction_tables.pdf https://agner.org/optimize/calling_conventions.pdf Все пять одним архивом: https://agner.org/optimize/optimization_manuals.zip Главная страница: https://agner.org/optimize/ Если хотите понимать performance не на уровне «ну там компилятор сам всё оптимизирует», а по-настоящему - это хороший старт.

В nginx аллокатор памяти устроен почти как указатель, который двигается только вперёд. Идея простая: под запрос выделяется пул памяти, а дальше nginx просто «отрезает» куски из большого блока по мере необходимости. Никаких сложных free lists, минимум накладных расходов на каждую аллокацию и меньше проблем с фрагментацией. Пока запрос живёт, память только раздаётся вперёд. Когда запрос завершён, весь пул освобождается одним действием. Почему это быстро: - не нужно освобождать каждый маленький объект отдельно - не нужно искать подходящий свободный блок - нет постоянной борьбы с фрагментацией - жизненный цикл памяти совпадает с жизненным циклом запроса - код остаётся предсказуемым для CPU cache Это хороший пример инженерного компромисса: nginx не пытается сделать универсальный malloc на все случаи жизни. Он использует знание своей нагрузки - много короткоживущих объектов внутри одного запроса - и делает под это максимально простой аллокатор. Иногда самый быстрый менеджер памяти - это просто указатель, который идёт вперёд.