Лично мне кажется, что это не те абстракции, за которые я хотел бы платить. Мне вполне достаточно статического отображения платформозависимых кодов в платформонезависимые, и не каждый раз при каждом сравнении, а один раз, при первом их появлении. Дальше можно сравнивать коды по значению, писать `switch`-и и это будет дёшево.
Ситуаций, где мне потребовалось бы явно работать с платформозависимыми кодами вне платформенных обёрток, я стараюсь не допускать. Остаётся платформозависимое описание ошибки, которое нужно протащить через платформонезависимый код. Вот для него виртуальный вызов вполне адекватен, но и без него можно было бы просто протащить необрабатываемый char* (правда, его пришлось бы вычислять нелениво).
А сейчас я плачу в каждом сравнении, чтобы иметь возможность расширять категории ошибок в runtime, что мне за всю мою практику не понадобилось ни разу.
В одной из своих статьей Страуструп писал:
> In general, C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.
Для разработчиков LLVM и для меня это место так не выглядит. Но интересно было бы увидеть примеры активного расширения system_error в настоящих проектах (boost предлагать не надо).
При сравнении error_code и error_condition делается минимум один виртуальный вызов, если они эквивалентны, и минимум два, если нет. Это дорого.
В libstd++ (стандартная библиотека C++ на debian) между версиями 3.4.18 и 3.4.21 есть проблемы с совместимостью. Если такие два теста собрать на Ubuntu Trusty, а запустить на Ubuntu Xenial, первый выдаст неверный результат, а второй упадёт.
Ситуаций, где мне потребовалось бы явно работать с платформозависимыми кодами вне платформенных обёрток, я стараюсь не допускать. Остаётся платформозависимое описание ошибки, которое нужно протащить через платформонезависимый код. Вот для него виртуальный вызов вполне адекватен, но и без него можно было бы просто протащить необрабатываемый char* (правда, его пришлось бы вычислять нелениво).
А сейчас я плачу в каждом сравнении, чтобы иметь возможность расширять категории ошибок в runtime, что мне за всю мою практику не понадобилось ни разу.
В одной из своих статьей Страуструп писал:
> In general, C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.
Для разработчиков LLVM и для меня это место так не выглядит. Но интересно было бы увидеть примеры активного расширения system_error в настоящих проектах (boost предлагать не надо).
Увы, у технологии есть и минусы:
При сравнении
error_codeиerror_conditionделается минимум один виртуальный вызов, если они эквивалентны, и минимум два, если нет. Это дорого.С такими минусами, в частности, столкнулись в LLVM и обходят их так:
https://github.com/llvm-mirror/llvm/commit/803fe1968007aa7a9c4f9674af648c9840f02a11
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/Errc.h