8

我目前执行以下操作，编译器（MSVC2008 / 以及 2010）没有抱怨它，但我不确定这是否是一个坏主意：

#ifndef FOO_H_
#define FOO_H_

// note, FOO_H_ is not a comment:
#endif FOO_H_

我以前总是这样写，#endif // FOO_H_但我发现自己今天没有这样做，并认为这很奇怪，因为显然我已经有一段时间没有使用评论方法了。

这是我应该回顾所有标题并修复（它是一个跨平台应用程序）的坏习惯，还是可以保持原样？

4

4 回答 4

6

严格来说（根据标准中的语法），在同一行的指令之后不允许使用标记#endif（注释是可以的，因为它们在比预处理指令更早的翻译阶段被删除 - 阶段 3 与 4）。

但是，MSVC 似乎允许它 - 我不会继续寻求修复这些（因为它们不会引起问题），但可能会在您修改包含它们的标题时记下修复它们。

当然，如果您的其他受支持的编译器发出有关它们的诊断信息，则修复它们可能更为紧迫。

于 2010-08-11T18:48:26.307 回答
5

这是不行的，它是无效的，AFAIK。许多编译器在这之后会忽略额外的文本，#endif并且经常会发出警告。您应该添加//以使其成为评论。

于 2010-08-11T18:46:11.153 回答
4

有了其他人发布的内容，我想我可能会帮助您实际纠正问题。（假设它在许多文件中。）

您可以使用 Visual Studio 中的查找和替换功能一次更正所有有问题的行。只需将 Find What: to"\#endif {[a-zA-Z\.\_]+}$"和 Replace With: to设置为"#endif //\1"（并确保在查找选项下选中了 Use: [Regular Expressions]。）

并在整个解决方案上做到这一点，你应该很高兴。

（请先备份您的项目，我已经对此进行了测试，它似乎按预期工作，但使用它需要您自担风险。）

于 2010-08-11T19:00:11.773 回答
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
{
}

Most modern compiler take into account his could happen and stick an extra EOL token on included files to prevent this from happening (technically not allowed but I can't think of a situation where it would cause a problem).

The problem is that some older compilers don't provide this extra token (more standards compliant) but as a result you can potentially end up compiling the above code (as a result they tend to warn you about two things 1) missing EOL in source files and 2) things after the #endif

于 2010-08-11T20:44:35.237 回答