📂 Шпаргалка по Big O (временная и пространственная сложность)

На картинке — большая наглядная таблица, которая помогает быстро оценивать “сколько это будет работать” и “сколько это съест памяти”.

Здесь в одном месте собраны Big O для основных структур данных и их операций, а также для популярных алгоритмов сортировки, с акцентом на best/average/worst случаи и сравнение time vs space.

Сохрани, чтобы на лету выбирать подходящую структуру/алгоритм и прикидывать узкие места.

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

std::scoped_lock: берём два mutex без риска дедлока.

Когда нужно залочить несколько мьютексов, эта мелочь экономит часы отладки “редких зависаний”.

Часто пишут так и не замечают проблему:

std::mutex m1, m2;

void a() {
    std::lock_guard<std::mutex> l1(m1);
    std::lock_guard<std::mutex> l2(m2);
    // работа с общими данными
}

void b() {
    std::lock_guard<std::mutex> l2(m2);
    std::lock_guard<std::mutex> l1(m1);
    // работа с общими данными
}

На первый взгляд всё ок, но если два потока одновременно зайдут в a() и b(), один может держать m1 и ждать m2, а второй держать m2 и ждать m1. Это классический дедлок, который может проявляться “раз в неделю” и очень дорого стоит.

Правильный вариант в C++17 — std::scoped_lock, который лочит сразу несколько мьютексов одним объектом:

std::mutex m1, m2;

void a() {
    std::scoped_lock lock(m1, m2);
    // работа с общими данными
}

void b() {
    std::scoped_lock lock(m1, m2);
    // тот же порядок, тот же механизм
}

Смысл в том, что std::scoped_lock использует безопасный механизм захвата нескольких мьютексов, поэтому тебе не нужно вручную следить за порядком lock-ов и ловить редкие зависания на проде.

🔥 std::scoped_lock — простая привычка, которая убирает целый класс дедлоков, когда ресурсов больше одного, а потоков больше одного.

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

📂 Напоминалка для работы с HTTP-запросами!

Например, GET используется для получения данных, POST — для создания новых записей, а DELETE — для удаления.

На картинке — 9 самых популярных методов HTTP-запросов, которые стоит держать под рукой каждому разработчику.

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

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

☕️ CP-Algorithms — это справочник по алгоритмам и структурам данных!

Он собрал в себе статьи с реализациями на C++, пошаговыми объяснениями и анализом сложности. Отлично подойдёт для тех кто хочет вспомнить материал для олимпиадного программирования и технических собеседований.

📌 Оставляю ссылочку: cp-algorithms.com

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

std::filesystem: почему на Windows “file not found”, хотя путь выглядит правильным?

Частая причина — кодировка: путь пришёл как UTF-8, а std::filesystem::path из std::string на Windows конвертируется через текущую ANSI code page, и в итоге получается другой путь.

Вот типичный случай, который внезапно даёт false:

std::filesystem::path p = "C:\\data\\report_2026.txt";
bool ok = std::filesystem::exists(p);

Если p получен из внешнего мира (JSON/HTTP/CLI/конфиг) и он в UTF-8, на Windows такой std::string не обязан трактоваться как UTF-8 — и на пути с не-ASCII символами в реальности всё “ломается” тихо.

Правильная привычка: если вход у тебя UTF-8 — создавай path через u8path:

auto p = std::filesystem::u8path(u8"C:\\data\\report_2026.txt");
bool ok = std::filesystem::exists(p);

Если путь уже в wide-форме (Windows API/GUI), используй wide-строку:

std::filesystem::path p = L"C:\\data\\report_2026.txt";
bool ok = std::filesystem::exists(p);

🔥 На Windows не полагайся на path из обычного std::string, если строки у тебя UTF-8. Для путей с не-ASCII символами выбирай u8path или wide.

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