🍪 Как std::hex меняет поведение вывода?

Манипуляторы — не просто функции. Они изменяют внутренние флаги потока.

💡 Под капотом — состояние

std::ostream хранит std::ios_base::fmtflags:

std::cout << std::hex << 255;  // ff
std::cout << 10;               // a (всё ещё hex!)

⚡️ Флаги остаются:

std::cout.setf(std::ios::hex, std::ios::basefield);
// Эквивалентно std::hex

💡 Сохранение состояния:

std::cout << std::hex << 255;
// Или
std::ios oldState(nullptr);
oldState.copyfmt(std::cout);
// ... вывод ...
std::cout.copyfmt(oldState); // Восстановление

❗️Манипуляторы — это состояние. Не забывай сбрасывать флаги в коде.


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом

🔗 libfoo.a vs libfoo.so: что выбрать?

Статическая и динамическая линковка — это выбор между размером бинарника и удобством обновлений.

❗️Статическая линковка (.a на Linux, .lib на Windows):

g++ main.cpp -static -o program

✅ Один файл, работает везде
❌ Большой размер (мегабайты вместо килобайт)
❌ Обновление библиотеки = пересборка всего


❗️Динамическая линковка (.so на Linux, .dll на Windows):

g++ main.cpp -o program  # По умолчанию

✅ Маленький бинарник
✅ Обновление библиотеки не требует пересборки
❌ Нужна библиотека на целевой системе
❌ "DLL hell" / dependency conflicts


🐸 Когда что использовать:

Статика: embedded, CLI-утилиты, дистрибуция
Динамика: системные демоны, плагины, shared libs


💡 Проверить зависимости: ldd ./program (Linux)


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#константная_правильность

🍪 Почему compare_exchange_weak может "случайно" провалиться?

Многие разработчики думают, что compare_exchange_weak — это просто облегчённая версия compare_exchange_strong. На самом деле у неё есть неочевидное поведение: она может вернуть false, даже если значение совпадает.


🍿 Как это работает:

На некоторых архитектурах (ARM, PowerPC) атомарные операции реализованы через инструкции load-link/store-conditional (LL/SC). Процессор помечает адрес памяти при чтении и проверяет при записи — не изменился ли он.

Но вот проблема: между LL и SC может произойти spurious failure — ложный отказ. Это случается, если:

• Произошло переключение контекста
• Кеш-линия была вытеснена
• Другой процессор обратился к соседней памяти

std::atomic<int> counter{0};
int expected = 0;
// Может вернуть false, даже если counter == 0!
bool success = counter.compare_exchange_weak(expected, 1);

✈️ На x86 такого нет — там используется инструкция CMPXCHG, которая атомарна на уровне железа. Но спецификация C++ допускает spurious failures для переносимости.


💡 Практический вывод:

Всегда используй compare_exchange_weak в цикле. Для однократных попыток бери compare_exchange_strong — она гарантирует, что false означает реальное несовпадение значений.


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#под_капотом