Атомарный доступ к полю без изменения его типа!
Иногда нужно синхронизировать доступ к полю структуры, но менять его тип на
Объявим структуру и создадим атомарную ссылку на поле:
Теперь можно безопасно работать с полем из нескольких потоков:
🔥
📣 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 делает атомарными любые переменные — удобно, когда нельзя менять исходные типы, но нужна потокобезопасность.Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤5👍4
В этой статье:
• Как устроен разбор HTTP-запросов и формирование корректных ответов.
• Как реализовать роутинг, раздачу статики и работу с конфигом сервера.
• Как сделать неблокирующий ввод-вывод и обработку нескольких клиентов.🔊 Продолжай читать по ссылке!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10🔥6👍3
Когда обработчиков для std::variant становится много, код может расползаться, а паттерн overload собирает все ветки в одном месте и делает чтение проще.
В этом гайде:
• Покажем минимальный helper overload, который объединяет несколько лямбд;
• Разберем пример с разными типами в std::variant, чтобы увидеть структуру обработчика;
• Применим тот же прием к обработке событий, где важна явность каждой ветки.
После этого вы сможете писать обработчики visit компактно и при этом сохранять строгую типизацию.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤9👍4🤝1
В этой статье:
• Как зарождался OpenCV и какую роль в этом сыграли люди из Intel.• Почему развитие проекта во многом определяли случайности, энтузиазм и удачные решения.• Как OpenCV смог вырасти в инструмент мирового уровня и получить признание сообщества.🔊 Продолжай читать по habr!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥4👍3
Почему unordered_map может быть медленнее map?
Потому что в реальном коде все сложнее, чем просто
На бумаге
У
Из-за этого код в духе:
не всегда оказывается быстрее, чем:
То есть контейнер “быстрее по учебнику” может проиграть в проде.
🔥 Для важного кода контейнер лучше мерить, а не выбирать по мифу про O(1).
📣 C++ Ready | #совет
Потому что в реальном коде все сложнее, чем просто
O(1) против O(log N).На бумаге
unordered_map выглядит очевидным победителем. Но в жизни у него есть цена: хеширование ключа, коллизии, rehash и более хаотичный доступ к памяти.У
map асимптотика хуже, но иногда она ведет себя стабильнее. Особенно если важны предсказуемость, порядок элементов или нормальная locality на конкретных данных.Из-за этого код в духе:
sum += um["user_" + std::to_string(i)];
не всегда оказывается быстрее, чем:
sum += m["user_" + std::to_string(i)];
То есть контейнер “быстрее по учебнику” может проиграть в проде.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤7👍6
❤9👍4🔥4
Когда инвалидируются итераторы в STL-контейнерах?
Одна из самых неприятных ошибок в C++ — сохранить итератор, указатель или ссылку на элемент контейнера, а потом продолжить использовать их после изменения контейнера.
Проблема в том, что после некоторых операций такие объекты становятся невалидными. Код может ещё долго “работать”, а потом внезапно упасть или начать давать странные результаты.
Частый случай —
Пример:
С
•
•
•
У
Пример:
А вот у
Хороший паттерн: не хранить итераторы дольше, чем нужно и после операций изменения контейнера получать итераторы заново.
🔥 Если контейнер изменился, старым итераторам и ссылкам лучше больше не доверять.
📣 C++ Ready | #практика
Одна из самых неприятных ошибок в 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 поведение стабильнее: вставка обычно не ломает уже существующие итераторы, но удаление элемента инвалидирует итератор именно на него.Хороший паттерн: не хранить итераторы дольше, чем нужно и после операций изменения контейнера получать итераторы заново.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤7👍5
This media is not supported in your browser
VIEW IN TELEGRAM
Этот репозиторий настоящий мета-каталог по самым разным технологиям. Внутри собраны тысячи подборок с библиотеками, инструментами, статьями и гайдами по программированию. Отдельные разделы посвящены языкам C# и C++, где можно найти библиотеки, фреймворки, проекты и обучающие ресурсы.
Оставляю ссылочку: GitHub📱
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍8🔥7
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝41🔥28👍9❤1