Тестирование С++ 17 в критически важных системах безопасности

В настоящее время я думаю о C++ в критическом для безопасности программном обеспечении (DO-178C DAL-D) и определениях стандарта кодирования. Я смотрел на MISRA C++, которому снова исполнилось 10 лет, и пропускает все функции C++ 11... 17.

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

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

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

Я создаю небольшой проект для тестирования этих идей и в настоящее время полностью сосредоточен на "дайте компилятору проверить ваши предположения". Например, мы только начали использовать [[nodiscard]] и обнаружили, по крайней мере, две ошибки таким образом в течение первого часа. Но какие аспекты современного C++ были разработаны и должны использоваться с учетом безопасности?

Ответ 1

Сначала это приходит мне на ум:

atomic и memory_model: они позволяют писать переносимый код в контекстно-зависимых контекстах.
unique_ptr: упрощает обработку памяти
override позволяет находить ошибки во время компиляции.
constexpr, если код написан ближе к тому, где он используется, что помогает записывать меньше ошибок (иногда, чтобы специализировать поведение в соответствии с параметром шаблона, вы должны написать класс с n специальностями. Теперь вы можете использовать if constexpr с n ветвями вместо).

и т.д.... в некотором смысле, учитывая преимущества четкости кода и переносимости, я думаю, что каждая функция С++ 11/14/17 помогает.

Ответ 2

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

По моему не очень скромному мнению, существует несколько особенностей языка, то есть стандартные возможности языка программирования общего назначения, которые оба выходят за рамки допустимых стандартов и стоят времени и энергии, чтобы спорить с вами в ходе оценки. Если вы нацелены на более высокий уровень абстракции (что тоже хорошо для безопасности, хотя вряд ли кто-нибудь открыто признает это, потому что это сделает половину индустрии безопасности безработной, а другую половину сильно устаревшей), тогда вы Лучше прибегнуть к языку, специфичному для домена, и приложить усилия к безупречной компиляции (к источнику) к стандартной совместимой платформе. Если вы не работаете в инженерной культуре, которая позволяет это, то вы можете прибегнуть к некоторым исправлениям, которые предлагает другой ответ, но всегда трудно убедительно переносить намерение и значение неспецифических мер с другой безопасностью инженеров (выделенный язык, специфичный для домена, намного проще как для поддержки, так и для объекта).

Тем не менее, я думаю, что прогресс в параллельном программировании современных C++ скоро будет входить в стандарты.