我目前正在执行以下操作，编译器（MSVC2008 /以及2010）并没有抱怨它，但我不确定这是不是一个坏主意：
#ifndef FOO_H_
#define FOO_H_
// note, FOO_H_ is not a comment:
#endif FOO_H_
我以前总是把它写成#endif // FOO_H_，但我发现自己今天不这样做，并认为这很奇怪，因为显然我暂时没有完成评论方法。
这是一种不好的做法，我应该通过我的所有标题并修复它（它是一个跨平台的应用程序），还是可以保持原样？
答案 0 :(得分：6)
严格地说（根据标准中的语法）在同一行的#endif指令之后不允许使用令牌（注释可以，因为它们在翻译的早期阶段被删除而不是预处理指令 - 阶段3 vs. 4）。
然而，MSVC似乎允许它 - 我不会继续寻求解决这些问题（因为它们不会导致问题），但是当您修改具有问题的标题时，可能会记住修复它们它们。
当然，如果您的其他受支持的编译器发出有关它们的诊断信息，则修复它们可能更为紧迫。
答案 1 :(得分：5)
不行，AFAIK无效。许多编译器忽略了#endif之后的额外文本，但经常会对此发出警告。您应该添加//以使其成为评论。
答案 2 :(得分：4)
随着其他人发布的内容，我想我可能会帮助您实际纠正问题。 （假设它在许多文件中。）
您可以使用visual studio中的“查找和替换”功能一次性纠正所有有问题的行。只需将查找内容设置为"\#endif {[a-zA-Z\.\_]+}$"并将替换为：设置为"#endif //\1"（并确保在查找选项下选中使用：[正则表达式]。）
在整个解决方案中做到这一点，你应该好好去。
（请先备份您的项目，我已经对此进行了测试，似乎按预期工作但使用此风险需要您自担风险。）
答案 3 :(得分：1)
为什么你的编译器应该警告你。
说你的头文件是这样的：
#ifndef X
#define X
// STUFF
// The next line does not contain an EOL marker (can happen)
#endif
现在您从源
中包含此内容#include "plop.h"
class X
{
}
当编译器在技术上包含文件时，扩展源应该如下所示
#define X
// STUFF
// The next line does not contain an EOL marker (can happen)
#endif class X
{
}
大多数现代编译器会考虑到他可能会发生并在包含的文件上添加额外的EOL令牌以防止这种情况发生（技术上不允许但我不能想到会导致问题的情况）。
问题是一些较旧的编译器不提供这个额外的令牌（更符合标准），但结果你可能最终编译上面的代码（因此他们倾向于警告你关于两件事1）源文件中的EOL和#endif
之后的事物