包括警卫的 Misra 警告答案

【问题标题】：Misra warning for include guard包括警卫的 Misra 警告
【发布时间】：2016-11-10 10:55:04
【问题描述】：

这是关于 MISRA C++ 2008 指南中的 MISRA 规则 16-0-2

Macros shall only be #define'd or #undef'd in the global namespace.

我理解这条规则，但我的 polyspace misra 检查工具抱怨在文件开头声明的以下包含保护声明为不合规。我想如果这个文件本身包含在另一个命名空间中，就会发生这种情况，但我的头文件不是这种情况。

代码中还有哪些其他错误可能导致此问题？

#ifndef FOO_H
#define FOO_H

... code etc ...

#endif

注意： Misra 指南中引用的示例是

#ifndef MY_HDR
#define MY_HDR     // Compliant


namespace NS
{
    #define FOO   // Non- Compliant
    #undef FOO    // Non-Compliant
}
#endif

【问题讨论】：

这是一个……奇怪的规则，它并不是说命名空间无论如何都会影响预处理器，但这听起来好像就是这样。
@unwind 我相信这就是规则的重点。因此，不知道没有命名空间-宏交互的开发人员不能假设宏在命名空间内。
规则的前提（或背后的推理）是宏不尊重范围，因此，如果要使用它们，请将它们放在所有范围之外。请注意，16-0-3 无条件禁止使用#undef。对于 OP，请尝试提供一个 MCVE（即使它需要包含一个包含您的标头以及您的标头的源文件）——人们至少能够推断出原因。
您能否创建一个非常简单的 hello-world 程序，其中包含您的标头 - 您是否会在此处遇到同样的违反规则的错误？如果不是，则需要返回确实导致错误的代码，并查看其整个上下文。
@Sirish 这意味着它可能是使用包含文件的上下文。也许在产生错误的头文件之前包含的头文件中正在执行一些奇怪的事情。也许最简单的方法是在有问题的文件上手动运行预处理器并手动检查它。

标签： c++ misra

【解决方案1】：

如果这些标头保护被放置在任何大括号之外（在全局命名空间中），那么您的代码就没有问题，而您的工具就坏了。向 Polyspace 发送错误报告。

此规则背后的基本原理是预处理器指令不应放置在大括号内（在命名空间声明或函数等内），因为它们的范围始终是全局的，无论它们放置在何处。

【讨论】：