Тестирование контрактов C++20 (утверждений)
Херб Саттер представил выступление на конференции ACUU о будущем исключений в C++ и предстоящих контрактах для замены или улучшения существующих утверждать.
Он постулирует следующие правила обработки ошибок:
Повреждение системы (например, переполнение стека): завершить
Ошибка программирования (например, нарушение предусловия): утверждения, контракты
Устранимая ошибка (например, сбой сети): исключение, код ошибки
Хотя я согласен, я не использую этот подход и по существу объединяю 2 и 3 в один. Я делаю это, потому что не знаю, как проверять утверждения или предстоящие контракты. Оба используют схожие механизмы, их нарушение приводит к завершению программы и вызову необязательных обработчиков перед этим.
Из документация (выделено мной):
A program may be translated with one of two violation continuation modes:
- off (default if no continuation mode is selected): after the execution of the violation handler completes, std::terminate is called;
- on: after the execution of the violation handler completes, execution continues normally.
Implementations are encouraged to not provide any programmatic way to query, set, or modify the build level or to set or modify the violation handler.
Это означает, что тестовые программы, которые будут проверяться на соответствие контрактам, потребуют дополнительного переключателя компиляции. Хотя мне это не нравится, я понимаю, почему это будет сделано именно так. Больше беспокоит последняя часть, и вопрос по ней был поднят. Если возможность установить собственный обработчик нарушения контракта определяется реализацией, она не будет единообразной для разных наборов инструментов. Таким образом, любые тесты контрактов не будут переносимыми, если это вообще возможно. Установка его в качестве еще одного параметра для компоновщика также была бы довольно неудобной (и определенно не переносимой).
В настоящее время тестирование против assert невозможно, потому что оно просто прерывает программу, а пользовательский обработчик не может этого предотвратить, насколько мне известно. С контрактами это должно было быть возможно с помощью пользовательского обработчика и переключателя сборки, но, как оказалось, это также может быть невозможно (или определяется реализацией).
Или есть ли какой-либо другой способ тестирования против утверждений и контрактов, который мне не хватает?
@NicolBolas Да, конечно, но проблема почти та же. Разница в том, что будет возможность отключить прерывание при вызове обработчика. Но если пользовательский обработчик не будет разрешен, не будет возможности проверить, был ли он вызван (был нарушен контракт) или нет.
Ответы 1
Существует не так много различий в реализации в отношении нарушений контракта. «уровень сборки» определяет, происходит ли проверка контракта вообще. Обработчик нарушений будет вызываться для всех проверенных контрактов, которые не выполняются.
Прототип обработчика определяется спецификацией. Единственная разница в реализации обработчика нарушений заключается в том, как вы его устанавливаете. Обратите внимание, что «определяется реализацией» не означает «не позволяет этому происходить». То есть стандарт говорит, что буду - это механизм для установки обработчика, и этот механизм буду должен быть задокументирован вместе с реализацией (вот что означает «определяется реализацией», а не просто «не указано»). Что именно представляет собой этот механизм, зависит от реализации, но его отсутствие является опцией нет.
Единственная реальная проблема, которая может возникнуть, — это если несколько реализаций решат разрешить пользователям указывать обработчик, благословляя конкретное глобальное имя, и если эти реализации используют другое глобальное имя. Однако, учитывая, что выбор глобального имени — плохая идея по многим причинам (конфликты с существующим кодом, макросы и т. д.), маловероятно, что это будет проблемой в действительности. Так что, скорее всего, они выберут очевидный механизм: переключатель компилятора, который указывает имя функции, используемой в качестве обработчика.
Обратите внимание, что одна из причин сделать определение обработчика статическим, а не определяемым во время выполнения, заключается в том, чтобы убедиться, что переключатель является переключателем компилятор, а не переключателем компоновщика. В конце концов, компилятор — это тот, кто выдает любой код проверки концепции. Таким образом, компилятор может просто использовать имя рассматриваемой функции в указанном коде проверки.
Да, конечно, разные компиляторы могут/будут иметь разные переключатели компилятора для определения того, какая функция вызывается. Но у них уже есть разные переключатели для генерации отладочной информации, уровней оптимизации и вообще всего остального. Таким образом, какую бы кроссплатформенную систему тестирования вы ни использовали, она уже должна уметь обрабатывать такие различия. Обработчик нарушений — это еще один.
"В настоящее время тестирование против assert невозможно, потому что оно просто прерывает программу, а пользовательский обработчик не может этого предотвратить, насколько мне известно." При обсуждении контрактов обычно говорят о контракте
[[assert:]], а не о макросеassert.