Указание обработчика нарушений для контрактов

Поддержка контрактного программирования на C++ был принят в рабочем проекте C++20 в Рапперсвиле. Одной из частей этой языковой функции является понятие обработчика нарушений, который будет вызываться при нарушении контракта.

Отчет о поездке Херба Саттера говорится, что:

Вы можете установить свой собственный обработчик нарушений и отправить сборку релиза с возможностью включения принудительного применения во время выполнения.

Но формулировка в [dcl.attr.contract], в этой статье добавлено:

Обработчик нарушений программы — это функция типа «noexceptopt функция (ссылка lvalue на const std​::​contract_­violation), возвращающая void», и определяется способом, определяемым реализацией. [...] Не должно быть программного способа установки или изменения обработчика нарушений. Реализация определяет, как устанавливается обработчик нарушений для программы и как устанавливается значение аргумента std​::​contract_­violation ([support.contract.cviol]), за исключением случаев, указанных ниже.

Мне это очень непонятно. Как реализация может позволить мне установить собственный обработчик нарушений непрограммным способом? Что мне придется делать с gcc, clang и msvc?


c++ c++20
person Barry    schedule 03.07.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Как реализация может позволить мне установить собственный обработчик нарушений непрограммным способом?

Это для реализации, чтобы определить, но я подозреваю, что это будет какой-то параметр командной строки. Вы бы назвали функцию, а компилятор/компоновщик сделал бы ее обработчиком нарушений. А если бы не это, то они, вероятно, выбрали бы какое-то конкретное имя функции, которую вы реализуете.

Дело в том, что используемая функция является статической с точки зрения абстрактной модели C++. Когда компилятор запускается, он точно знает, какая функция будет вызвана, во многом подобно системному вызову main, а также той части программы, которая обрабатывает возвращаемые значения main.

person Nicol Bolas    schedule 03.07.2018
comment
Мне это кажется принципиально странным... Думаю, нам просто нужно подождать и посмотреть, когда это будет реализовано? - person Barry; 03.07.2018
comment
@Барри: Это не так уж и странно. Дело в том, что вызов функции статичен, в отличие от вызова terminate обработчиков, который является динамическим. Таким образом, компиляторы могут оптимизировать его более эффективно. - person Nicol Bolas; 03.07.2018
comment
Я не думаю, что очень важно оптимизировать вызов обработчика нарушений. Типа - это даже не то, что должно происходить в правильной программе, верно? Кажется более важным упростить указание для нескольких компиляторов. - person Barry; 03.07.2018
comment
@Barry: я не думаю, что это вопрос оптимизации производительности самого вызова. Это скорее вопрос генерации кода для проверки нарушения контракта. Таким образом, все статично. Также могут быть проблемы с DLL/SO. - person Nicol Bolas; 03.07.2018