🍬 EXPECT_DEATH не ловит исключение. Он запускает ваш код в отдельном процессе и ждёт его смерти

Если думал, что death-тест в GoogleTest — это просто проверка «упадёт или нет», то это не так. На деле фреймворк изолирует ваш код в дочернем процессе, дожидается его завершения и проверяет, что тот умер именно так, как вы ожидали. Сам тест-раннер при этом остаётся жив — в этом весь смысл.

💡Когда вы пишете EXPECT_DEATH(stmt, "regex"), фреймворк форкает текущий процесс. Дочерний выполняет stmt, родитель через waitpid() ждёт его завершения и анализирует статус выхода.

❓ Зачем вообще отдельный процесс? Потому что abort(), std::terminate или сработавший assert убивают процесс по-настоящему. Поймать это в том же процессе как исключение нельзя — управление уже не вернётся. Единственный способ протестировать смерть, не убив сам тест-раннер, — изолировать её в ребёнке.

EXPECT_DEATH(
    { std::abort(); },
    ".*"
);

❗️ Родитель и ребёнок после форка — два независимых адресных пространства (copy-on-write). Краш в ребёнке для родителя — просто ненулевой код возврата или сигнал.

❗️Death-тест — это не try/catch, это управляемое самоубийство подпроцесса. Если держать это в голове, перестаёшь удивляться, почему std::cout внутри блока ведёт себя странно.


❓ А вы проверяете abort()-ветки или оставляете их «на авось»?

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

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

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

🤕😱 Канала не хватает одного — твоего буста. Не лайка, не репоста. Именно буста, который реально качнёт канал вверх

Если думал, что от одного голоса ничего не зависит, то это не так. На деле каждый буст поднимает уровень канала и открывает ему новые возможности. А тебе за это больше полезностей в канале‼️

❓ За что бустить?

За Сторис — наш формат для небольших, но полезных находок, которые жалко оставлять «за кадром»:

• интересные инструменты
• короткие технические заметки
• полезные ссылки
• вопросы для программистов
• быстрые опросы


👾 Жми кнопку буста под этим постом. Этим ты внесёшь ощутимый вклад в развитие канала.

➡️ Буст канала

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

🎱 Проекции: Что такое проекция?

Одна из полезнейших тем в C++ диапазонах — это проекции.

Проекция — это функция, которая «извлекает» ключ из элемента перед тем, как алгоритм с ним работает. Подавляющее большинство алгоритмов из std::ranges принимают необязательный параметр proj; по умолчанию там std::identity — элемент идёт как есть.


⏰ ranges::sort — сортировка по полю

Возьмём те самые задачи из прошлого поста:

struct Task { std::string name; int priority; };
std::vector<Task> tasks = { {"Код", 1}, {"Деплой", 3}, {"Тесты", 2} };

std::ranges::sort(tasks, {}, &Task::priority);
// порядок: Код(1), Тесты(2), Деплой(3)

Здесь {} — компаратор по умолчанию (ranges::less), а &Task::priority — проекция. Для каждой пары алгоритм считает less(a.priority, b.priority). Помните, в свёртках, чтобы сложить по priority, пришлось писать лямбду? Тут поле достаёт сама проекция.


🎨 Проекция по указателю на член

Самый частый случай — &Тип::поле. И работает не только в sort:

// найти задачу с priority == 3
auto it = std::ranges::find(tasks, 3, &Task::priority);
// *it == Task{"Деплой", 3}

// посчитать задачи с priority > 1
auto n = std::ranges::count_if(tasks,
    [](int p){ return p > 1; }, &Task::priority);
// n == 2

Обратите внимание на порядок: у find проекция идёт сразу после искомого значения (компаратора у него нет), а у count_if — после предиката. У каждого алгоритма свой набор параметров, проекция в нём всегда последняя.


🧁 Проекцией может быть что угодно вызываемое

Не только поле. Подойдёт указатель на метод, лямбда, свободная функция — всё, что переваривает std::invoke:

std::vector<std::string> v = {"apple", "fig", "banana"};
std::ranges::sort(v, {}, &std::string::size);   // по длине
// "fig"(3), "apple"(5), "banana"(6)

std::vector<int> nums = {-5, 2, -1, 3};
std::ranges::sort(nums, {}, [](int x){ return std::abs(x); }); // по модулю
// -1, 2, 3, -5

🎁 Проекция меняет ВЗГЛЯД, но не результат

Это главное, что надо уложить в голове. Проекция влияет только на то, ПО ЧЕМУ алгоритм принимает решения. Возвращает он по-прежнему исходные элементы, а не спроецированные значения:

auto top = std::ranges::max(tasks, {}, &Task::priority);
// top — это Task{"Деплой", 3}, а НЕ число 3
// (и это копия: max возвращает элемент по значению)

auto it = std::ranges::min_element(tasks, {}, &Task::priority);
// *it — Task{"Код", 1}, итератор на сам элемент (копии нет)

То есть проекция — это «по какому ключу», а не «во что превратить». Если нужно именно превратить элементы — это уже views::transform.


🍕 У бинарных алгоритмов проекций две

Там, где сравниваются два диапазона (equal, mismatch, …), проекций тоже две — по одной на каждый вход:

std::vector<Task> a = { {"X", 1}, {"Y", 2} };
std::vector<Task> b = { {"A", 1}, {"B", 2} };

// равны ли списки по приоритетам, игнорируя имена?
bool same = std::ranges::equal(a, b, {}, &Task::priority, &Task::priority);
// {} — предикат по умолчанию, дальше proj1 и proj2
// true: 1 == 1, 2 == 2

‼️ Несколько подводных камней

• Порядок аргументов. proj идёт после компаратора, а не вместо. sort(tasks, &Task::priority) — указатель на поле не годится в компараторы → простыня ошибок. Правильно: sort(tasks, {}, &Task::priority).
• Проекцию зовут много раз. В sort — на каждом сравнении, O(n log n) вызовов. Тяжёлую (парсит строку) выгоднее посчитать заранее и сортировать по готовым ключам.
• Проекция ≠ преобразование вывода. На выходе всегда исходные элементы. Превратить их — это views::transform.
• Свёртки без проекций. У fold_* параметра proj нет (хотя у for_each и transform есть). «Свернуть по полю» — только лямбдой или через views::transform.


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

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

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

😊 doctest: тесты прямо рядом с кодом

Что если тесты можно писать в том же файле, что и реализацию, без потери скорости сборки? Именно эту идею продаёт doctest.

Это самый быстрокомпилируемый фреймворк из популярных: подключение заголовка почти не утяжеляет сборку. А с флагом DOCTEST_CONFIG_DISABLE все тесты вырезаются из релизного бинарника полностью.

Такой подход меняет привычку: проверку можно положить сразу под функцию, пока логика свежа в голове. Тест становится живой документацией, а не отдельным проектом в папке tests/.

int add(int a, int b) { return a + b; }
TEST_CASE("add") { CHECK(add(2, 2) == 4); }

✏️ Держите ли вы тесты отдельно от кода — или допускаете их соседство в одном файле?


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

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

#междусобойчик