и это плохо".
Также можно сказать и про отсутствие noexcept на ф-и.
Если писать exception-safe код - приходится думать о каждой не-noexcept ф-и - "отсутствие noexcept - тянет за собой отсутствие noexcept".
Это усложняет как и написание кода, так и его понимание.
Например, если string_view c-tor не noexcept, нужно ли писать такой код ?
auto user_function1(std::vector<char>& v) {
modify_state(v);
try
{
return std::string_view(&v.back(), 1);
}
catch (...)
{
rollback_state();
throw;
}
}
Также, часть in-house библиотек вообще билдится с выключенными исключениями - любое нарушение контракта/исключение приводит к крешу; такие библиотеки - уже не standard-conforming.
Согласен, отсутствие noexcept напрягает, особенно в деструкторах. На это как минимум будут спамить анализаторы
Лучше писать такое через RAII и не заморачиваться с явным продумыванием noexcept. Выключаяя исключения вы выходите за пределы стандарта C++. Сейчас идёт работа по стандартизации подобного поведения, но не понятно чем всё закончится. А вообще - спасибо! Добавлю ваши мысли в документ. Как парировать аргумент "не noexcept влечёт не coexcept" - не знаю
Обсуждают сегодня