🍋 Почему ваши мелкие TCP-пакеты не отправляются сразу?

Отправляете данные через send(), а они висят в буфере 200мс? Это не баг — это Nagle's algorithm, и он работает с 1984 года.

❓ Как это работает

Когда вы пишете в TCP-сокет небольшие порции данных (например, по 10 байт), ядро не отправляет их сразу. Вместо этого алгоритм Nagle ждёт:

• Либо пока накопится достаточно данных
• Либо пока придёт ACK на предыдущий пакет
• Либо истечёт таймаут (~200мс)

// Отправка без Nagle — каждый send() = отдельный пакет
int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

// Теперь send(sock, "A", 1) уходит немедленно

🍴 Зачем он нужен?

В эпоху медленных каналов накладные расходы TCP/IP заголовков (40 байт) на каждый байт полезных данных убивали пропускную способность. Nagle агрегирует данные, снижая оверхед до приемлемых значений.

✏️ Подробнее в статье...

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом

🍔 Сборник ресурсов по современному C++

Список ресурсов, которые помогут людям изучить современный C++ и более поздних версий

👉 GitHub

🔹 Курс «Математика для разработки AI-моделей»
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

🏃‍♀️ Proglib Academy

#буст

😔 Почему большинство критичных уязвимостей связаны с управлением памятью в C++?

C++ даёт прямой доступ к памяти. Это мощь и проклятие одновременно. Microsoft подсчитал: за последние 12 лет 70% их CVE — memory corruption. Разберём топ-5 механизмов, которые превращают код в дыры безопасности.


💔 Buffer Overflow — перезапись стека

char buffer[8];
strcpy(buffer, userInput); // 20 байт в 8-байтовый буфер

Данные выходят за границы и перезаписывают return address на стеке. Атакующий контролирует, куда прыгнет выполнение после ret. Под капотом: стек растёт вниз, локальные переменные располагаются перед сохранённым RIP. Переполнение идёт вверх по адресам прямо в критичные данные.

Защита: std::string, санитайзер ASan (-fsanitize=address), stack canaries.


⚡️ Use-After-Free — висячий указатель

int* ptr = new int(42);
delete ptr;
*ptr = 100; // UB: память отдана аллокатору

Аллокатор переиспользует освобождённый блок для нового объекта. Ваша запись портит чужие данные, часто vtable объекта. Это даёт атакующему контроль над virtual dispatch — RCE через подмену указателя на функцию.

Защита: unique_ptr, ptr = nullptr после delete, MemorySanitizer.


❌ Integer Overflow в размерах

size_t size = count * sizeof(T); // count из сети
void* buf = malloc(size); // size обернулся в 0

Беззнаковое переполнение легально в C++, но создаёт логическую ошибку. Аллокатор выделяет крошечный буфер, затем туда пишутся гигабайты → heap overflow → перезапись metadata аллокатора.

Защита: проверка count < SIZE_MAX / sizeof(T), -fsanitize=unsigned-integer-overflow.


😡 Double Free

delete ptr;
// ...
delete ptr; // Ломает free list аллокатора

Аллокатор хранит free-блоки в linked list. Double free записывает адрес блока в free list дважды. Следующий malloc() может вернуть один и тот же блок двум владельцам → два указателя на одну память → запись через один портит данные другого.

Защита: RAII, умные указатели, heap profiler.


💰 Format String — printf как бэкдор

printf(userInput); // "%x %x %n"

%x читает стек (утечка адресов ASLR), %n пишет по адресу из стека. Атакующий конструирует цепочку спецификаторов для записи произвольного значения в произвольный адрес.

Защита: всегда printf("%s", input), -Wformat=2.


🍕 Практический вывод

Все уязвимости эксплуатируют UB и прямой доступ к памяти. Защитный стек 2026: компилятор (-D_FORTIFY_SOURCE=2), санитайзеры на CI, ASLR+DEP в рантайме. Но даже это не заменит понимание механизмов на уровне стека и кучи.


✏️ Какие санитайзеры используете в проекте?


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#буст

🍬 Почему assert() убивает тесты, а ASSERT_EQ не трогает другие?

assert() крашит процесс. ASSERT_EQ() — нет. Оба проверяют условия. В чём разница на уровне исполнения?
Механизм обработки неудачи в Google Test построен на исключениях и return, а не на abort().

⚡️ Как работает assert():

#define assert(expr) \
  ((expr) ? (void)0 : __assert_fail(...))

При провале вызывается __assert_fail(), которая делает abort() — немедленное завершение процесса. Никаких cleanup, никаких других тестов.

🔍 Как работает ASSERT_EQ:

#define ASSERT_EQ(a, b) \
  if (auto result = Compare(a, b); !result) { \
    RecordFailure(result); \
    return; // <-- ключевое!
  }

✏️ При провале:

1. Ошибка записывается в объект теста
2. Выполняется return из функции теста
3. Фреймворк перехватывает управление
4. Следующий тест запускается нормально

🪐 Технический нюанс:

В helper-функциях ASSERT_* использует специальный механизм — макрос генерирует код, который бросает внутреннее исключение Google Test, если тест не void. Это позволяет прервать выполнение даже из вложенных функций.

🍋 Практический вывод:

Никогда не используй assert() в production коде, который тестируешь — это помешает тестированию граничных случаев. Используй throw или возвращай error codes.

В тестах всегда используй ASSERT_*/EXPECT_*, а не assert().

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#буст

🔧 Guidelines Support Library: как Microsoft проверяет параметры

GSL — это не просто модная библиотека. Это набор практик от создателей C++, упакованный в код😎

#include <gsl/gsl>

// ❌ Традиционная проверка
void setAge(Person& p, int age) {
    if (age < 0 || age > 150) {
        throw std::invalid_argument("Invalid age");
    }
    p.age = age;
}

// ✅ GSL: семантика ясна из кода
void setAge(Person& p, int age) {
    Expects(age >= 0 && age <= 150); // Precondition
    p.age = age;
    Ensures(p.age == age); // Postcondition
}

❗️Что даёт GSL:

• Expects() — preconditions (проверка входа)
• Ensures() — postconditions (проверка выхода)
• gsl::not_null<T*> — указатель, который не может быть null

void process(gsl::not_null<int*> data) {
    // Компилятор гарантирует: data != nullptr
    *data = 42; // Безопасно без if
}

‼️ В debug режиме — runtime проверки, в release — могут быть отключены.

👉 Библиотека

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#константная_правильность

🔥 Почему v.erase(remove(...)) быстрее цикла с erase()?

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

🍬 Наивный подход:

for (auto it = v.begin(); it != v.end(); ) {
    if (*it == target)
        it = v.erase(it); // каждый раз сдвиг O(n)
    else
        ++it;
}

Если удаляешь k элементов из вектора размера n, получаешь O(k×n) операций копирования. При k≈n/2 это O(n²).

⚡️ Erase-remove idiom:

v.erase(std::remove(v.begin(), v.end(), target), v.end());

remove() делает O(n) перемещений, erase() делает один сдвиг хвоста O(n). Итого O(n) вместо O(n²).

❗️Вывод: Это не микрооптимизация, а правильный алгоритм. При удалении из середины вектора — всегда используй erase-remove.

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом