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

Иногда нужно синхронизировать доступ к полю структуры, но менять его тип на 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 | #совет

Когда инвалидируются итераторы в STL-контейнерах?

Одна из самых неприятных ошибок в C++ — сохранить итератор, указатель или ссылку на элемент контейнера, а потом продолжить использовать их после изменения контейнера.

Проблема в том, что после некоторых операций такие объекты становятся невалидными. Код может ещё долго “работать”, а потом внезапно упасть или начать давать странные результаты.

Частый случай — std::vector: если после push_back() произошла reallocation, все итераторы, указатели и ссылки на элементы инвалидируются.

Пример:

std::vector<int> v{1, 2, 3};

auto it = v.begin();
v.push_back(4); // может перевыделить память

int x = *it; // UB: итератор мог стать невалидным

С std::vector важно помнить:
• push_back, emplace_back, insert могут инвалидировать все итераторы, если контейнер перевыделил память;
• erase инвалидирует итераторы от удалённого элемента и дальше до конца;
• clear инвалидирует всё.

У std::unordered_map тоже есть ловушка: при rehash инвалидируются все итераторы.

Пример:

std::unordered_map<int, int> m{{1, 10}, {2, 20}};

auto it = m.find(1);
m.reserve(100); // может вызвать rehash

int x = it->second; // итератор может быть уже невалиден

А вот у std::list и std::map поведение стабильнее: вставка обычно не ломает уже существующие итераторы, но удаление элемента инвалидирует итератор именно на него.

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

🔥 Если контейнер изменился, старым итераторам и ссылкам лучше больше не доверять.

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

☕️ Ultimate Awesome — огромная подборка с ресурсам!

Этот репозиторий настоящий мета-каталог по самым разным технологиям. Внутри собраны тысячи подборок с библиотеками, инструментами, статьями и гайдами по программированию. Отдельные разделы посвящены языкам C# и C++, где можно найти библиотеки, фреймворки, проекты и обучающие ресурсы.

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

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

Почему std::remove не удаляет элементы из vector?

Потому что алгоритм не меняет размер контейнера. Он просто сдвигает нужные элементы в начало диапазона и возвращает итератор на новый логический конец.

После такого кода:

std::vector<int> v = {1, 2, 3, 2, 4};
std::remove(v.begin(), v.end(), 2);

размер вектора остаётся 5. В хвосте просто остаются элементы, которые больше не считаются валидными.

Чтобы реально удалить их из контейнера, нужен второй шаг:

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

🔥 std::remove не удаляет, он только переставляет элементы. Настоящее удаление начинается с erase.

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