CppDeveloperRoadmap — репозиторий, в котором собраны книги, идеи для пэт-проектов и полезные ресурсы для изучения. Все материалы разбиты на уровни junior, middle и senior.

Оставляю ссылочку: Github 📱

📣 C++ Ready | #репозиторий

std::span + subspan(): “нарезай” буфер на части без копий и лишних new!

Это особенно удобно для протоколов и парсинга, где есть заголовок, тело и хвост.

Часто делают так: копируют куски в новые контейнеры.

std::vector<uint8_t> header(const std::vector<uint8_t>& buf, size_t n) {
    return {buf.begin(), buf.begin() + n};
}

std::vector<uint8_t> payload(const std::vector<uint8_t>& buf, size_t n) {
    return {buf.begin() + n, buf.end()};
}

Проблема в том, что это лишние аллокации и копирование: на каждом разрезе создаётся новый буфер, а в горячем коде парсинга это быстро становится дорогим.

std::span не владеет памятью, зато позволяет сделать “вид” на нужный участок, и subspan() как раз возвращает такой срез.

Вместо копий — просто виды на исходный буфер:

struct PacketView {
    std::span<const std::uint8_t> hdr;
    std::span<const std::uint8_t> body;
};

PacketView split(std::span<const std::uint8_t> buf, std::size_t n) {
    return {
        buf.subspan(0, n),
        buf.subspan(n)
    };
}

Использование выглядит так же просто:

int main() {
    std::vector<std::uint8_t> buf = {1,2,3,4,5,6,7,8};

    auto p = split(buf, 3);
    // p.hdr -> {1,2,3}
    // p.body -> {4,5,6,7,8}
}

Важно помнить: span живёт только пока живут исходные данные, поэтому нельзя возвращать span на временный объект или локальный буфер, который скоро уничтожится.

🔥subspan() — это “срез без копии”: идеально для парсинга и разборки буферов, когда нужно быстро выделять части и не плодить новые вектора.

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

☕️ Отличная статья — про то, как в RESTinio устроены “многоэтажные” шаблоны и зачем они нужны!

В этой статье:
• Понять, зачем в сервере столько уровней шаблонов вообще
• Увидеть, как через типы собирается конфигурация API сервера
• Разобраться, как шаблоны уменьшают бойлерплейт без рантайма лишнего

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

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

Почему {} иногда спасает от скрытых багов с конверсиями?

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

В C++ есть безопасная привычка: использовать uniform initialization с фигурными скобками. Она запрещает narrowing-конверсии — то есть те, где можно потерять данные.

Например, вот это должно насторожить:

int a = 300;
std::uint8_t b{a};

std::uint8_t обычно хранит 0..255, а 300 не влезает. С {} компилятор обязан ругнуться, вместо того чтобы молча обрезать значение.

То же самое с дробными числами:

double pi = 3.14;
int x{pi};

С {} ты не сможешь “случайно” потерять дробную часть — компилятор остановит сборку.

🔥 Итог: если инициализируешь числа (особенно при приведениях типов), чаще используй {} — это дешёвый способ ловить “тихие” обрезания на этапе компиляции.

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

✍️ Preshing on Programming — блог про низкоуровневый C++ и многопоточность!

Технический блог Джеффа Прешинга, где он объясняет сложные темы “на пальцах”: атомики и memory ordering, lock-free подходы, тонкости работы компилятора/CPU и практические паттерны для производительного кода.

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

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

📂 Шпаргалка по 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 | #практика