C++ Academy
По всем вопросам- @workakkk РКН: clck.ru/3FmxJF #VRHSZ
Ko'proq ko'rsatish📈 Telegram kanali C++ Academy analitikasi
C++ Academy (@cpluspluc) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 15 536 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 8 063-o'rinni va Rossiya mintaqasida 41 910-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 15 536 obunachiga ega bo‘ldi.
15 Sentabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 71 ga, so‘nggi 24 soatda esa -3 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 15.89% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 6.83% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 470 marta ko‘riladi; birinchi sutkada odatda 1 062 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 21 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent c++, github, linux, api, архитектура kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“По всем вопросам- @workakkk
РКН: clck.ru/3FmxJF
#VRHSZ”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 16 Sentabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
slow двигается на 1 узел
fast — на 2
Если цикл есть, они обязательно встретятся.
После встречи один указатель возвращаем в head, а дальше оба двигаем по одному узлу. Следующая точка встречи — точное начало цикла.
Node *detect_cycle(Node *head) {
Node *slow = head, *fast = head;
while (fast && fast->next) {
slow = slow->next;
fast = fast->next->next;
if (slow == fast) {
slow = head;
while (slow != fast) {
slow = slow->next;
fast = fast->next;
}
return slow;
}
}
return NULL;
}
Сложность:
O(n) по времени
O(1) по памяти
Один из самых красивых примеров того, как простая математика по модулю превращается в очень практичный алгоритм.SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, size_t, count)
После препроцессора это превращается сразу в несколько функций:
- sys_write
- __se_sys_write
- __do_sys_write
Одна строка описывает системный вызов, а C-препроцессор через макросы и token pasting собирает остальную обвязку автоматически.
Именно поэтому код ядра Linux часто выглядит коротко, пока не начнёшь разворачивать макросы.CRC16(key) % 16384
Но есть важный трюк — hash tags.
Если ключ содержит часть в фигурных скобках, Redis хеширует только содержимое внутри {}:
{user100}:cart
{user100}:orders
Оба ключа будут вычислены по user100, поэтому попадут в один и тот же hash slot и, соответственно, на одну ноду.
Это нужно для multi-key операций в cluster mode.
Именно поэтому такие конструкции позволяют нормально использовать:
- MGET
- MSET
- транзакции
- Lua-скрипты с несколькими ключами
На уровне кода Redis сначала ищет {, затем }, и если внутри есть непустая строка — хеширует только её.
Небольшая деталь синтаксиса, которая на самом деле решает важную проблему распределённых операций в Redis Cluster.std::map<std::string, ...> не обязан создавать временный std::string при каждом поиске
Если ключ уже приходит как std::string_view, можно использовать transparent comparator:
std::map<std::string, int, std::less<>> status_codes{
{"not_found", 404},
{"timeout", 504}
};
std::string_view key = "timeout";
auto match = status_codes.find(key);FILE* можно обернуть в std::unique_ptr с собственным обработчиком освобождения:
#include <cstdio>
#include <memory>
struct FileCloser {
void operator()(std::FILE* file) const noexcept {
std::fclose(file);
}
};
using File = std::unique_ptr<std::FILE, FileCloser>;
Использование внутри функции:
File file{std::fopen("data.txt", "r")};
if (!file) {
return;
}
// Передаём FILE* в функции C-библиотеки
int ch = std::fgetc(file.get());
Когда file выйдет из области видимости, unique_ptr вызовет fclose. Это работает при обычном завершении функции, раннем return и раскрутке стека при исключении.
Так устроен RAII: время жизни ресурса связано со временем жизни объекта. Если fopen вернул nullptr, обработчик освобождения вызван не будет.header → отдельно payload → отдельноможно сделать один непрерывный блок памяти:
+----------------+ | struct msg | | len | +----------------+ | payload data[] | +----------------+Код:
struct msg {
uint32_t len;
uint8_t data[];
};
struct msg *m = malloc(sizeof(*m) + n);
Один malloc() → один блок памяти → один free().
Почему это любят в системном коде:
✅ меньше аллокаций
✅ лучше работа с CPU cache
✅ проще сериализация
✅ нет лишних указателей и разрозненных данных
Такой подход используется в низкоуровневом коде: ядрах, драйверах, сетевых стеках.
До C99 часто писали:
uint8_t data[1];
и вручную обходили ограничения языка.
Теперь data[] — официальный способ сказать:
«После структуры здесь будет динамический массив данных».
Маленькая особенность C, которая помогает писать быстрый код на уровне ядра.\0. Из-за этого strlen() каждый раз проходит весь буфер, а хранить произвольные бинарные данные становится неудобно.
Поэтому Redis использует собственную структуру SDS — Simple Dynamic Strings.
В памяти она выглядит примерно так:
[len][alloc][flags][данные...\0]
↑
sds
Перед самими данными Redis хранит метаданные:
- len — текущую длину;
- alloc — размер выделенной памяти;
- flags — тип заголовка.
Благодаря этому длина строки определяется за O(1), а свободное место известно заранее. При добавлении данных Redis не обязан каждый раз заново вычислять размер и перевыделять память.
SDS также остаётся совместимой со многими функциями C: указатель ведёт прямо на буфер, а в конце всё равно находится \0.
Но Redis не зависит от этого терминатора — длина хранится отдельно. Поэтому внутри строки могут находиться нулевые байты, изображения, сериализованные объекты и другие бинарные данные.
Важный нюанс: структура sdshdr из старых примеров сегодня упрощена. Современный Redis выбирает компактный заголовок sdshdr5, sdshdr8, sdshdr16, sdshdr32 или sdshdr64 в зависимости от размера строки.
Небольшой заголовок перед буфером решил сразу три проблемы: быстрое получение длины, безопасную работу с бинарными данными и эффективное расширение строк.
Источник:
https://redis.io/docs/latest/operate/oss_and_stack/reference/internals/internals-sds/
https://github.com/redis/redis/blob/unstable/src/sds.hO(n), но неудачный выбор опорного элемента может превратить поиск k-го элемента в O(n²).
В 1973 году Блум, Флойд, Пратт, Ривест и Тарьян предложили алгоритм median of medians, который гарантирует линейное время даже в худшем случае.
Идея:
1. Разделить массив на группы по 5 элементов.
2. Найти медиану каждой группы.
3. Рекурсивно найти медиану полученных медиан.
4. Использовать её как pivot для Quickselect.
int mom_pivot(int *arr, int n)
{
if (n <= 5) {
sort(arr, n);
return arr[n / 2];
}
int medians[(n + 4) / 5];
for (int i = 0; i < n; i += 5) {
int len = (n - i < 5) ? n - i : 5;
sort(arr + i, len);
medians[i / 5] = arr[i + len / 2];
}
return mom_pivot(medians, (n + 4) / 5);
}
Такой pivot не обязательно будет настоящей медианой массива, но он гарантированно не окажется слишком близко к краю. После разбиения отбрасывается достаточно большая часть элементов, поэтому рекурсия не деградирует.
Итоговая сложность поиска:
Средний случай: O(n)
Худший случай: O(n)
Дополнительная память: зависит от реализации
На практике randomized Quickselect часто быстрее из-за меньших констант. Median of medians нужен там, где важна строгая гарантия времени: real-time системы, adversarial input и библиотеки с предсказуемой производительностью.1 - байт загружается
- 0 - вместо него ставится ноль
Самое интересное начинается, когда маска полностью нулевая:
#include <x86intrin.h>
void f(const char *p) {
_mm512_maskz_loadu_epi8(0, p);
}
При нулевой маске память фактически не читается, а результатом становится 512-битный вектор из нулей.
То есть значение p в таком случае не влияет на результат, а компилятор при оптимизации вообще может удалить весь вызов.
Хороший пример того, насколько необычно работают masked-load инструкции в AVX-512.LPPROC_THREAD_ATTRIBUTE_LIST, который нужен при расширенном создании процессов и потоков.
Проблема в API простая:
- сначала нужно отдельно узнать размер буфера
- потом вручную выделить память
- вызвать InitializeProcThreadAttributeList
- после работы обязательно вызвать DeleteProcThreadAttributeList
- и только потом освободить сам буфер
Chen предлагает обернуть всё это в RAII через WIL, чтобы очистка происходила автоматически.
Из интересного:
- отдельный helper для освобождения списка
- безопасное получение нужного размера
- разбор того, почему CTAD здесь не помогает
- перегрузки через SFINAE, чтобы не ловить неоднозначность с int
- возможность сразу предзаполнить список атрибутами
- можно заранее оставить место под дополнительные атрибуты, которые добавятся позже
В итоге работа с LPPROC_THREAD_ATTRIBUTE_LIST становится заметно аккуратнее и меньше похожа на ручной Win32-ритуал с кучей cleanup-кода.
https://devblogs.microsoft.com/oldnewthing/20260813-00/?p=112611