在安全关键系统中测试 C++17答案

【问题标题】：Testing C++17 in safety critical systems在安全关键系统中测试 C++17
【发布时间】：2018-12-13 12:54:09
【问题描述】：

我目前正在考虑安全关键软件 (DO-178C DAL-D) 中的 C++ 和编码标准的定义。我在看 MISRA C++，它又有 10 年的历史了，它错过了所有 C++11…17 的特性。

虽然在安全性方面保持保守通常不是一个坏主意，但新的语言功能可能对安全性有益。

在审查期间，人们必须争论您做出某些决定的原因。人们总是会争辩说，新的语言特性使代码更清晰……因此关于误解的错误更少；特别是如果编译器能够测试和验证您的假设。

但很难找到比“让事情更清晰”更突出安全方面的语言特征。现代 C++ 的哪些方面真正有助于安全？

我正在建立一个小型练习项目来测试这些想法，目前完全专注于“让编译器检查你的假设”。比如我们刚刚开始使用[[nodiscard]]，在第一个小时内就发现了至少两个这样的bug。但是现代 c++ 的哪些方面是在设计和使用时应考虑到安全性的？

【问题讨论】：

谷歌“AUTOSAR C++”
这不是特定于 c++17 的，但保持你的构建链合理地更新将提供额外的安全性。额外的编译器警告和静态分析工具总是越来越好。使这些保持最新只会更容易支持未来的版本。

标签： c++ safety-critical

【解决方案1】：

我首先想到这些：

atomic 和 memory_model ：它们允许在并发/无锁上下文中编写可移植代码。
unique_ptr：有助于简化内存处理
override 可让您在编译时发现错误。
constexpr if 使代码写得更接近它使用的地方，这有助于编写更少的错误（有时，为了根据模板参数专门化一个行为，你会编写一个具有n 特化的类。现在你可以使用@987654327 @ 与 n 分支代替）。

等等...在某种程度上，考虑到代码清晰度和可移植性的好处，我认为 C++11/14/17 的每个特性都有帮助。

【讨论】：

【解决方案2】：

人们总是会争辩说，新的语言特性使代码更清晰......因此关于误解的错误更少；特别是如果编译器能够测试和验证您的假设。

在我看来，语言特性很少，即标准通用编程语言特性都超出了允许的标准，并且值得花时间和精力去争论你在评估中的方式。如果您的目标是更高级别的抽象（这对安全来说也是一件好事，尽管您几乎找不到任何人公开承认这一点，因为这会使一半的安全行业失业，而另一半则严重过时），那么您最好求助于特定领域的语言，并将努力完美地编译（源代码）到符合标准的平台。如果您不在允许这样做的工程文化中工作，那么您可以求助于此处其他答案提出的一些补丁，但总是难以令人信服地将非特定措施的意图和意义传递给其他安全工程师（专用的领域特定语言更容易支持或反对）。

也就是说，我认为现代 C++ 并行编程的进步会相对较快地进入标准。

【讨论】：