📂 Напоминалка по типам серверов в современных системах!

Например, DNS-сервер преобразует доменное имя в IP-адрес, а кеш-сервер ускоряет отдачу данных, снижая нагрузку на базу.

На картинке — фундамент серверной инфраструктуры, без которой не работает ни одно современное приложение.

Сохрани, чтобы не забыть!

📣 C++ Ready | #ресурс

Заменить значение и забрать старое — std::exchange!

Иногда нужно “переключить” переменную на новое значение и при этом сохранить старое: например, сбросить флаг, обнулить указатель, забрать ресурс у объекта. Вместо двух строк и временной переменной есть удобная функция std::exchange.

Сначала типичный “ручной” вариант:

int old = value;
value = 0;
use(old);

Теперь то же самое одной строкой: std::exchange возвращает старое значение и записывает новое:

int old = std::exchange(value, 0);
use(old);

Частый практический кейс — “забрать” указатель и обнулить его, чтобы избежать повторного использования:

T* take_ptr(T*& p) {
    return std::exchange(p, nullptr);
}

И ещё один популярный пример — move-конструктор, где нужно забрать ресурс и оставить исходный объект в безопасном состоянии:

struct Buffer {
    int* data = nullptr;

    Buffer(Buffer&& other) noexcept
        : data(std::exchange(other.data, nullptr)) {}
};

🔥 std::exchange делает намерение явным: “забрать старое, поставить новое” — меньше кода, меньше шансов забыть сбросить состояние.

📣 C++ Ready | #практика

👍 Отличная статья — про RAII как про дизайн-инструмент, а не только про “освободить ресурс”

В этой статье:
• Понять, как RAII помогает строить архитектуру и инварианты
• Увидеть примеры управления разными ресурсами (не только памятью)
• Научиться делать код устойчивым к исключениям и “утечкам ответственности”

🔊 Продолжай читать на Habr!

📣 C++ Ready | #статья

Безопасный “побитовый каст” без UB — std::bit_cast!

Иногда нужно посмотреть на биты значения: получить IEEE754-представление float, собрать/разобрать сетевой пакет, сделать хеш по битам, интерпретировать double как uint64_t.

Многие делают это через reinterpret_cast или “указательную магию” — и ловят UB из-за strict aliasing и выравнивания.

Сначала типичный “ручной” (опасный) вариант:

float f = 1.0f;
auto u = *reinterpret_cast<std::uint32_t*>(&f); // UB!
use(u);

Теперь то же самое правильно одной строкой: std::bit_cast (C++20) копирует биты между типами одинакового размера:

float f = 1.0f;
auto u = std::bit_cast<std::uint32_t>(f);
use(u);

Частый практический кейс — быстро проверить знак/экспоненту float без математики:

bool is_negative(float x) {
    auto bits = std::bit_cast<std::uint32_t>(x);
    return (bits >> 31) != 0;
}

Ещё один популярный пример — получить “сырой” uint64_t из double для стабильного сравнения/логирования битов:

std::uint64_t raw_bits(double d) {
    return std::bit_cast<std::uint64_t>(d);
}

И обратная операция — восстановить значение из битов (тоже безопасно, если размер совпадает):

double from_bits(std::uint64_t bits) {
    return std::bit_cast<double>(bits);
}

🔥 std::bit_cast делает намерение явным: “мне нужны биты, а не преобразование значения” — без reinterpret_cast, без строгого алиасинга, меньше шансов поймать UB.

📣 C++ Ready | #практика

❤️ USACO Guide — роадмап по олимпиадному программированию!

Бесплатный “one-stop shop” для подготовки к USACO: структурированные разделы от Intro и Bronze до Platinum/Advanced, где в каждом модуле есть объяснение темы, советы по реализации, подборка задач для практики и разборы/редакции

📌 Оставляю ссылочку: usaco.guide

📣 C++ Ready | #ресурс

Почему std::move не “перемещает”?

Многие думают, что std::move(x) физически “переносит” данные и очищает x. Но std::move ничего не двигает — это всего лишь приведение к rvalue-ссылке, то есть сигнал компилятору: “этот объект можно перемещать”.

Проблема начинается, когда после std::move мы продолжаем пользоваться объектом как раньше:

std::string s = "hello";
std::string a = std::move(s);

std::cout << s; // ❌ логическая ошибка

После перемещения объект обязан оставаться валидным, но его состояние становится неопределённым (у std::string часто будет пусто, но полагаться на это нельзя). Поэтому любые “проверю что осталось” и “ещё раз использую” — источник багов.

Правильное правило простое:
• std::move(x) = “я отказываюсь от значения x”
• после этого x можно только: присвоить новое значение / уничтожить / вызвать безопасные операции, не зависящие от содержимого.

🔥 Итог: std::move — не перенос, а разрешение на перенос. Если ты пишешь std::move, считай, что “объект дальше мне не нужен” — так код становится предсказуемым и без скрытых сюрпризов.

📣 C++ Ready | #совет

Антипаттерн: # define DEBUG 1 vs NDEBUG

Часто для отладочного кода делают что-то вроде #define DEBUG 1 и оборачивают всё в #ifdef DEBUG.

Работает? Да.
Надёжно? Не всегда.

Проблема в том, что такой DEBUG — не стандартный, и он легко расходится с реальным типом сборки. В итоге можно случайно оставить отладочный код в релизе.

В стандарте C++ уже есть специальный макрос для этого — NDEBUG. Если NDEBUG не определён, значит это debug-сборка. Если NDEBUG определён, значит релиз.

Именно на него завязаны assert и многие стандартные проверки.

Плохой вариант:

#define DEBUG 1

void foo(int x) {
#ifdef DEBUG
    std::cout << "x = " << x << "\n";
#endif

    work(x);
}

Если забыть убрать DEBUG или определить его не там — отладочный код спокойно уедет в прод.

Правильный вариант — ориентироваться на NDEBUG:

void foo(int x) {
#ifndef NDEBUG
    std::cerr << "x = " << x << "\n";
#endif

    work(x);
}

Теперь всё согласовано:
• debug-сборка → логирование и проверки есть
• release (-DNDEBUG) → код полностью вырезается компилятором

Точно так же стоит писать и свои отладочные макросы:

#ifndef NDEBUG
    #define DBG_LOG(msg) std::cerr << msg << "\n"
#else
    #define DBG_LOG(msg) ((void)0)
#endif

🔥 Использование NDEBUG — это не мелочь, а дисциплина сборки: отладочный код никогда не попадёт в релиз случайно, и всё поведение будет согласовано со стандартными механизмами C++.

📣 C++ Ready | #практика