C++ Academy

🖥 Большинство “простых” shuffle-алгоритмов дают кривой рандом Частая ошибка:

for (int i = 0; i < n; i++) {
    int j = rand() % n;
    swap(a[i], a[j]);
}

На вид всё нормально: каждый элемент случайно меняется местами с другим. Но проблема в вероятностях. Для массива из n элементов существует n! перестановок. Хороший shuffle должен давать каждой перестановке одинаковый шанс. Наивный вариант делает n шагов, и на каждом шаге выбирает индекс из полного диапазона 0..n-1. В итоге некоторые перестановки появляются чаще других. Правильный подход - Fisher-Yates shuffle:

for (int i = n - 1; i > 0; i--) {
    int j = random(0, i);
    swap(a[i], a[j]);
}

Идея простая: на каждом шаге мы выбираем элемент только из ещё не зафиксированной части массива. Сначала выбираем последний элемент из всего массива. Потом предпоследний - из оставшихся. Потом следующий - из ещё меньшего диапазона. Так каждая перестановка получает одинаковую вероятность. В C++ лучше не писать через rand() % n, потому что там может быть ещё и modulo bias. Нормальный вариант:

std::mt19937 rng(std::random_device{}());

for (int i = n - 1; i > 0; --i) {
    std::uniform_int_distribution<int> dist(0, i);
    int j = dist(rng);
    std::swap(a[i], a[j]);
}

Shuffle - хороший пример, где код может выглядеть “рандомным”, но математически быть неправильным.

В C есть синтаксис, который выглядит как опечатка:

case '0' ... '9':

Кажется, что такой switch вообще не должен компилироваться. Но в GCC это работает. Это расширение называется case ranges — можно задавать сразу диапазон значений внутри case. Например:

case '0' ... '9':
    return DIGIT;

case 'a' ... 'z':
case 'A' ... 'Z':
    return LETTER;

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

Одна строка C, которая может сломать вам логику В C порядок вычисления аргументов функции не определён.

foo(i++, i++);

Из-за этого один и тот же код может дать разный результат: * gcc: foo(1, 0) * clang: foo(0, 1) Причина простая: компиляторы по-разному вычисляют аргументы. Такие вещи годами становились источником очень неприятных багов. Хорошая новость: сейчас -Wall обычно умеет это подсветить. Вывод банальный, но важный: не пишите код, который зависит от порядка вычисления аргументов.

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку Окружение решает больше, чем кажется. Собрал папки и каналы, где можно быстрее влиться в нужное направление, следить за трендами и не вариться в своём пузыре. AI: t.me/ai_machinelearning_big_data Python: t.me/pythonl Linux: t.me/linuxacademiya Хакинг: t.me/linuxkalii DevOps: t.me/DevOPSitsec Docker: https://t.me/+90Z5TAyfuNU5YmRi Golang: t.me/Golang_google Rust: t.me/rust_code C++: t.me/cpluspluc C#: t.me/csharp_1001_notes Java: t.me/javatg JavaScript: t.me/javascriptv React: t.me/react_tg Frontend: t.me/front PHP: t.me/phpshka Android: t.me/android_its Мобильная разработка: t.me/mobdevelop Базы данных: t.me/sqlhub Data Science: t.me/data_analysis_ml Big Data: t.me/bigdatai Математика: t.me/data_math Физика: t.me/fizmat Kubernetes: t.me/kubernetc GameDev: https://t.me/gamedev Haskell: t.me/haskell_tg Собеседования и карьера: DS собеседования: t.me/machinelearning_interview Python собеседования: t.me/python_job_interview Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка Frontend: https://t.me/addlist/mzMMG3RPZhY2M2Iy Полезное сверху: ИТ-мемы: t.me/memes_prog Английский для программистов: t.me/english_forprogrammers ИИ и технологии: t.me/vistehno 954 ГБ open-source курсов: https://t.me/+rKBQEMccAA01MTcy ИТ-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy Max Ai: https://max.ru/ai_machinelearning_big_data Max python: https://max.ru/pythonl ТЕХНО: https://max.ru/vistehno Max Go: https://max.ru/Golang_google Max Linux: https://max.ru/linuxkalii Devops: https://max.ru/DevOPSitsec C#: https://max.ru/csharp_ci C++: https://max.ru/cpluspluc SQL: https://max.ru/sqlhub Java: https://max.ru/javatg Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд.

Кто-то под именем Сатоши Накамото в 2008 году опубликовал идею, из которой выросла целая индустрия майнинга с огромным энергопотреблением. И до сих пор никто достоверно не знает, кто скрывается за этим именем. При этом сама базовая идея Proof of Work выглядит почти примитивно: берём число nonce, меняем его снова и снова, каждый раз считаем хэш и проверяем, попал ли результат ниже нужного target. Условно это выглядит так:

uint32_t nonce = 0;

while (1) {
    header.nonce = nonce;
    hash = sha256(sha256(header));

    if (hash < target)
        break;

    nonce++;
}

То есть майнинг Bitcoin в основе своей это гигантский перебор чисел с постоянным пересчётом SHA-256. Простой цикл, который в итоге породил ASIC-фермы, энергопотребление в масштабах стран и индустрию на миллиарды долларов.

🖥 C++26 закрывает одну из самых больных тем lock-free кода - безопасное удаление памяти. Проблема не в atomics. Проблема в том, что один поток уже убрал узел из структуры, а другой всё ещё может его читать. Удалишь слишком рано, получишь use-after-free. Поэтому в C++26 стандартизируют Hazard Pointers. Идея простая: поток заранее помечает объект как “я сейчас его читаю”. Пока хотя бы один reader держит такой hazard pointer, объект нельзя удалять. Удаление откладывается до момента, когда все читатели закончат работу. Это делает lock-free структуры вроде стеков, очередей и списков намного безопаснее. Lock-free программирование становится не магией, а чуть более нормальным инженерным инструментом.

Приглашаем на бесплатный открытый вебинар курса «Программист С»: «С без компромиссов: обработка ошибок и полиморфизм» Когда: 25 августа, 20:00 (мск) Язык С даёт полный контроль над памятью и железом, но за эту мощь приходится платить — в нём нет встроенных исключений и классов. Однако, это не значит, что отказоустойчивость и гибкость недоступны. На вебинаре разберём техники, которые обычно остаются за кадром, и покажем, как писать на С надёжно, масштабируемо и без ущерба для производительности. Что будет на вебинаре: Рассмотрим setjmp/longjmp — аналог исключений, который позволяет «телепортироваться» сквозь стек вызовов; Создадим виртуальные таблицы (vtable) — руками реализуем полиморфизм, как в C++; Соединим обе техники в одном проекте – создадим систему логирования с централизованной обработкой ошибок. Зарегистрироваться https://otus.pw/bn4O/?erid=2W5zFJBY3jX Бесплатное занятие приурочено к старту курса «Программист С» Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

⚡️ Linux может освободить RAM, не уничтожая сам диапазон виртуальной памяти процесса. Это как раз то, что делает madvise(MADV_DONTNEED) для anonymous mappings. Сценарий такой:

char *region = mmap(NULL, GB,
                    PROT_READ | PROT_WRITE,
                    MAP_PRIVATE | MAP_ANONYMOUS,
                    -1, 0);

// потрогали часть страниц

madvise(region, GB, MADV_DONTNEED);

После madvise виртуальные адреса остаются валидными. Процесс всё ещё «видит» тот же диапазон памяти. Но физические страницы, которые стояли за этим диапазоном, ядро может забрать обратно. То есть адресное пространство осталось, а реальная RAM освободилась. При следующем обращении к этому участку процесс получит свежие zero-filled страницы. Старых данных там уже не будет. Почему это полезно: * можно держать большой виртуальный регион без постоянного удержания RAM * аллокаторы могут возвращать неиспользуемые страницы ядру * long-running процессы меньше раздувают RSS * память можно переиспользовать без полного munmap и нового mmap Важная деталь: MADV_DONTNEED не означает «удали адреса». Это скорее сигнал ядру: «эти страницы мне сейчас не нужны, можешь забрать физическую память». Адреса остаются. Страницы уходят. Следующее чтение приносит нули.

⚙️ Обычный strcat() в цикле может незаметно превратить простую склейку строк в O(n²). Причина в том, что strcat() при каждом вызове сначала ищет конец уже собранной строки. Чем длиннее буфер, тем больше данных приходится повторно проходить. Например:

for (int i = 0; i < 100000; i++)
    strcat(buf, "chunk");

В бенчмарке сборка строки примерно на 1 МБ заняла около 4,1 секунды. Если же заранее выделить буфер и просто хранить текущую позицию записи:

char *p = buf;

for (int i = 0; i < 100000; i++) {
    memcpy(p, "chunk", 5);
    p += 5;
}

тот же объём собирается примерно за 0,4 мс. Разница больше чем в 10 000 раз. Мелочь, которую легко пропустить: проблема не в копировании строки, а в постоянном повторном поиске её конца.

⚡️ Fenwick Tree держится на одном битовом трюке Fenwick Tree, или Binary Indexed Tree, считает prefix sums за O(log n). Вся магия в операции:

i & -i

Она находит младший установленный бит числа. Почему это работает? В two’s complement число -i получается как инверсия битов i плюс 1. Когда мы делаем i & -i, остаётся только самый правый бит, равный 1. Например:

i = 12        // 1100
-i            // 0100 в нужной маске
i & -i = 4

Именно это значение говорит Fenwick Tree, на сколько нужно прыгнуть по индексам. Для обновления:

for (; i < MAXN; i += i & -i)
    tree[i] += v;

Мы идём вверх по структуре и обновляем все узлы, которые покрывают этот индекс. Для запроса суммы:

for (; i > 0; i -= i & -i)
    s += tree[i];

Мы идём вниз и собираем нужные блоки суммы. Одна и та же операция управляет двумя направлениями: * i += i & -i — перейти к следующему ответственному узлу * i -= i & -i — убрать последний блок из prefix sum Поэтому Fenwick Tree такой компактный: никаких явных рёбер, указателей и рекурсии. Только массив и битовая арифметика. Красота структуры в том, что дерево как бы спрятано внутри двоичного представления индекса.

📚 Библиотека для работы с SQLite в C++26 с использованием рефлексии Reflite — это библиотека на C++26, которая упрощает взаимодействие с SQLite, позволяя использовать обычные структуры как основу для выполнения запросов. Она поддерживает основные операции: вставка, удаление, выборка и обновление, избавляя от лишнего шаблона кода. 🚀 Основные моменты: - Легковесная библиотека в одном файле - Поддержка операций INSERT, DELETE, SELECT, UPDATE - Использует рефлексию для работы с типами структур - Не требует полной реализации SQL, фокус на простоте - Совместима с современными компиляторами C++26 📌 GitHub: https://github.com/KaruroChori/reflite #cpp

💡 Clang умеет показывать AST, и это один из лучших способов реально понять, что компилятор видит в вашем C/C++ коде. AST — это Abstract Syntax Tree, внутреннее представление программы после парсинга. Например, простой код:

int x = a + b * 2;

для компилятора — не просто строка текста, а дерево примерно такого смысла:

VarDecl
└── BinaryOperator +
    ├── a
    └── BinaryOperator *
        ├── b
        └── 2

Именно через такое представление компилятор понимает структуру выражений, типы, области видимости и то, какие преобразования можно выполнить дальше. У Clang AST можно получить напрямую:

clang++ -Xclang -ast-dump -fsyntax-only main.cpp

А в Compiler Explorer / Godbolt есть отдельный режим просмотра AST, поэтому можно менять код и сразу видеть, как перестраивается дерево. Особенно полезно разбирать так: * шаблоны; * перегрузку функций; * implicit conversions; * auto; * лямбды; * range-based for; * временные объекты; * разные формы инициализации. Если регулярно смотреть AST, C++ постепенно перестаёт выглядеть как набор «магических правил». Начинаешь видеть код примерно так, как его видит компилятор. 🔗 https://godbolt.org/z/cfc7h41bT #Cpp #Clang #Compiler #Programming

🎶 Оптимизированный аудиовизуализатор для Windows Spectrum — это легковесный аудиовизуализатор на C++, который обрабатывает звук в реальном времени и выводит его в консоль без разрывов экрана. Он использует FFTW3 для анализа аудиосигналов и обеспечивает точное визуальное представление частот. 🚀 Основные моменты: - Реализация на C++17 для Windows. - Низкое использование CPU и памяти. - Поддержка WASAPI для захвата системного звука. - Отображение в виде ASCII-графиков. - Легкий в использовании и установке. 📌 GitHub: https://github.com/majockbim/spectrum #cpp

⚡️ Один `static` - три разных смысла. Добро пожаловать в C. В C ключевое слово static меняет поведение в зависимости от того, где именно оно написано. ### 1. static у глобальной переменной

static int global;

Переменная имеет internal linkage - она доступна только внутри текущего .c файла. Это удобный способ спрятать детали реализации модуля. ### 2. static внутри функции

void foo(void) {
    static int count;
    count++;
}

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

foo(); // count = 1
foo(); // count = 2
foo(); // count = 3

### 3. static у функции

static void bar(void) {
}

Функция становится видна только внутри текущего translation unit. Другой .c файл вызвать bar() напрямую уже не сможет. Итого:

static global variable -> скрыть символ внутри файла
static local variable  -> сохранить состояние между вызовами
static function        -> скрыть функцию внутри файла

🔥 Поэтому static в C полезнее воспринимать не как одно конкретное поведение, а как подсказку проверить две вещи: lifetime и linkage. #C #Programming #SystemsProgramming #LowLevel #Cpp

⚡️ Генератор случайных чисел всего из трёх XOR и сдвигов В 2003 году Джордж Марсалья представил xorshift - один из самых простых и быстрых генераторов псевдослучайных чисел. Классический xorshift32:

uint32_t xorshift32(void)
{
    state ^= state << 13;
    state ^= state >> 17;
    state ^= state << 5;
    return state;
}

Фактически весь алгоритм:

shift → XOR
shift → XOR
shift → XOR

При ненулевом начальном state период может достигать:

2³² - 1

Никаких умножений, делений или тяжёлой математики, поэтому подобные RNG отлично подходят для игр, симуляций и procedural generation, где важна скорость. Но есть нюанс: xorshift нельзя использовать для криптографии. Его внутреннее состояние можно предсказать, поэтому для ключей, паролей и токенов нужны криптографически стойкие генераторы. Иногда действительно полезный алгоритм помещается буквально в три строки. #Programming #Algorithms #C #Random

Keylogger в несколько строк C? Почти. На самом деле это не «магия взлома», а raw mode в терминале. Обычно терминал ждёт Enter и сам обрабатывает ввод. А здесь программа отключает echo и canonical mode, поэтому видит каждое нажатие сразу. Именно так работают редакторы, TUI-приложения и терминальные игры. Важно: использовать только на своём вводе и в учебных целях. Перехват чужих клавиш - уже не программирование, а нарушение безопасности.

Лето, ИТ-Пикник и музыка известных артистов уже через несколько дней! 8 августа в Коломенском пройдет ИТ-Пикник. В программе — выступления проекта LAB Антона Беляева, IOWA, Cream Soda, Pompeya, мартина и Совы. А днем — научпоп-лекции, дискуссии об ИИ и больших языковых моделях, мастер-классы и интерактивы. Полезные знакомства и развлечения тоже будут. Зарегистрироваться и узнать подробности можно на сайте мероприятия. В билет входит +1 — можно позвать близких и друзей. До встречи в месте притяжения ИТ.

Четыре строки делают сложение `float` заметно точнее При последовательном сложении чисел с плавающей точкой часть младших битов теряется из-за округления. На больших массивах эта ошибка постепенно накапливается. Алгоритм Кэхэна хранит потерянную часть в отдельной переменной и компенсирует её на следующем шаге:

float kahanSum(const float *nums, int count)
{
    float sum = 0.0f;
    float correction = 0.0f;

    for (int i = 0; i < count; ++i)
    {
        float adjusted = nums[i] - correction;
        float next = sum + adjusted;

        correction = (next - sum) - adjusted;
        sum = next;
    }

    return sum;
}

Здесь correction запоминает ошибку округления, которая потерялась при предыдущем сложении. Обычная сумма быстрее, но Kahan Summation полезен там, где важна численная точность: - научные расчёты; - статистика и аналитика; - графика и симуляции; - обработка больших массивов; - накопление очень маленьких значений рядом с большими. Метод предложил Уильям Кэхэн в 1965 году. Небольшое усложнение цикла может заметно уменьшить ошибку без перехода на более тяжёлый числовой тип.

Оператор # в препроцессоре C превращает токены в строковые литералы ещё на этапе компиляции. Никакого преобразования во время выполнения не происходит. Ядро Linux использует этот трюк в макросах вроде WARN_ON(), чтобы вывести точное условие, которое не прошло проверку. Вы пишете выражение один раз, а препроцессор автоматически генерирует соответствующую строку. Один оператор - и ваши debug-сообщения остаются идеально синхронизированы с кодом.

LEA в x86 выглядит как инструкция для адресов, но компиляторы часто используют её как скрытый калькулятор. Формально LEA считает адрес без обращения к памяти:

lea eax, [rdi + 3]

Но по факту это обычная арифметика:

return x + 3;

Ещё хитрее:

lea eax, [rdi + rdi*4]

Это уже:

return x * 5;

Почему так делают? Потому что x86-адресация умеет base + index * scale + offset, а LEA позволяет использовать эту механику без чтения памяти. Бонус: LEA не трогает флаги процессора, в отличие от add. Красота C и asm в том, что за простой строкой x * 5 может стоять не mul, а маленький трюк архитектуры.