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

Question

我目前正在考虑安全关键软件（DO-178C DAL-D）中的C ++和编码标准的定义。我一直在看MISRA C ++，它已经有10年的历史了，并且错过了所有C ++ 11…17功能。

尽管对安全性持保守态度通常不是一个坏主意，但新的语言功能可能对安全性有益。

在审查过程中，您必须争论您为什么做出某些决定。人们总是可以辩称，新的语言功能使代码更清晰……从而减少了关于误解的错误；特别是如果编译器能够测试和验证您的假设。

但是，很难找到比“使事情更清晰”更能突出安全性的语言功能。关于安全性，现代C ++的哪些方面真正有用？

我正在建立一个小型练习项目来测试这些想法，目前完全专注于“让编译器检查您的假设”。例如，我们刚开始使用[[nodiscard]]，并在第一个小时内以这种方式发现了至少两个错误。但是，现代c ++的哪些方面在设计时应牢记安全性？

Answer 1

首先想到这些：

• atomic和memory_model：它们允许在并发/无锁上下文中编写可移植代码。
• unique_ptr：有助于简化内存处理
• override可让您在编译时查找错误。
• constexpr if使代码写得更接近使用位置，这有助于减少错误的发生（有时，要根据模板参数对行为进行专门化，您可以编写具有n专业化的类现在，您可以将if constexpr与n分支一起使用）。

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

Answer 2

人们总是可以辩称，新的语言功能使代码更清晰……从而减少了关于误解的错误；尤其是如果编译器能够测试和验证您的假设。

在我看来，

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

这就是说，我认为现代C ++并行编程的进步将很快进入标准。