📂 Напоминалка по HTTP vs HTTPS!

Например, HTTP передаёт данные в открытом виде, без шифрования. HTTPS работает поверх TLS и защищает соединение: выполняется проверка сертификата, обмен ключами и дальнейшая передача данных в зашифрованном виде.

На картинке — ключевые этапы установления соединения.

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

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

☕️ Red Blob Games — полезный сайт для визуального понимания алгоритмов!

Если тебе сложно понять алгоритмы по учебникам — этот ресурс решает проблему. Автор объясняет графы, геометрию, деревья, меши из геймдева через понятные визуализации и интерактивы. Сложные идеи здесь раскладываются на простые шаги.

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

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

Почему std::shared_ptr иногда тормозит даже без потоков?

На вид это просто умный указатель. Кажется, что раз всё в одном потоке — накладных расходов почти нет.

Но у shared_ptr есть счётчик ссылок в control block. Когда ты передаёшь shared_ptr по значению, на входе и выходе функции делается refcount++/refcount-- (обычно атомарно). В горячем коде это превращается в лишнюю работу, хотя логически ты “просто передал указатель”.

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

Если владение не шарится — лучше unique_ptr или значение. Если шаринг нужен — просто не копируй shared_ptr без причины.

void log(std::shared_ptr<Foo> p); // копия -> refcount++/--

void hot(const std::shared_ptr<Foo>& p) {
    for (int i = 0; i < 1'000'000; ++i)
        log(p);                   // лучше: log(const std::shared_ptr<Foo>&)
}

🔥 В hot path не передавай shared_ptr по значению — используй const std::shared_ptr<T>& (или unique_ptr, если шаринга нет).

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

Атомарный доступ к полю без изменения его типа!

Иногда нужно синхронизировать доступ к полю структуры, но менять его тип на std::atomic<T> невозможно — например, он используется сторонним API или загружается из сериализованного формата. В таких случаях поможет std::atomic_ref из C++20.

Объявим структуру и создадим атомарную ссылку на поле:

#include <atomic>

struct Data {
    int counter = 0;
};

Data d;
std::atomic_ref<int> a(d.counter);

Теперь можно безопасно работать с полем из нескольких потоков:

#include <thread>

std::jthread t1([&]{ a++; });
std::jthread t2([&]{ a += 2; });

🔥 std::atomic_ref делает атомарными любые переменные — удобно, когда нельзя менять исходные типы, но нужна потокобезопасность.

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

❤️ Нашёл полезный материал — как написать свой HTTP-сервер на C++ “как у nginx”!

В этой статье:
• Как устроен разбор HTTP-запросов и формирование корректных ответов.
• Как реализовать роутинг, раздачу статики и работу с конфигом сервера.
• Как сделать неблокирующий ввод-вывод и обработку нескольких клиентов.

🔊 Продолжай читать по ссылке!

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

✍️ Нашёл интересный материал на Хабре — история о том, как OpenCV прошёл путь от смелой идеи до одного из самых известных проектов в компьютерном зрении!

В этой статье:
• Как зарождался OpenCV и какую роль в этом сыграли люди из Intel.
• Почему развитие проекта во многом определяли случайности, энтузиазм и удачные решения.
• Как OpenCV смог вырасти в инструмент мирового уровня и получить признание сообщества.

🔊 Продолжай читать по habr!

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

Почему unordered_map может быть медленнее map?

Потому что в реальном коде все сложнее, чем просто O(1) против O(log N).

На бумаге unordered_map выглядит очевидным победителем. Но в жизни у него есть цена: хеширование ключа, коллизии, rehash и более хаотичный доступ к памяти.

У map асимптотика хуже, но иногда она ведет себя стабильнее. Особенно если важны предсказуемость, порядок элементов или нормальная locality на конкретных данных.

Из-за этого код в духе:

sum += um["user_" + std::to_string(i)];

не всегда оказывается быстрее, чем:

sum += m["user_" + std::to_string(i)];

То есть контейнер “быстрее по учебнику” может проиграть в проде.

🔥 Для важного кода контейнер лучше мерить, а не выбирать по мифу про O(1).

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