如何在启用 ANSI 的同时在 gcc 中启用 C++ 样式的注释？答案

【问题标题】：How do I enable C++ styled comments in gcc while leaving ANSI enabled?如何在启用 ANSI 的同时在 gcc 中启用 C++ 样式的注释？
【发布时间】：2010-09-21 14:32:46
【问题描述】：

这是我在哪里工作的一个问题，所以我做了一点挖掘，答案是 ExpertsExchange 问题。所以我把你交给最初的提问者，Manchung：

我有一个用纯 C 语言编写的项目，用于嵌入式系统。所以，我使用纯 C 来最小化代码大小。

当我编译项目时，我使用 -ansi 标志来确保代码符合 ANSI 标准。然而，使用这个 ansi 标志的缺点是我只能使用 C 风格的 cmets (/*cmets */)。当我需要使用嵌套的 cmets 时，这让我很头疼。

所以，我的问题是：我可以使用哪些开关/标志来允许我使用 C++ 样式的 cmets (// cmets) 同时保持启用 ANSI 检查？

这也概括了我的问题。

【问题讨论】：

对该问题的最高投票答案不再有效。我很想看到一个解决方案——就我而言，这是因为我试图在 Windows 和 Linux 之间强制执行跨平台代码兼容性。 Windows 主要需要符合 ANSI 的代码，但在系统标头中有 c++ 样式的 cmets。如果我不将它们标记为警告（并将其标记为错误），我的 Windows 开发人员将使用 c++ 样式的 cmets。在 GCC 中启用 c++ cmets 似乎是最简单的答案。

标签： c++ c gcc comments

【解决方案1】：

C 已经有 C++ 风格的 cmets 快十年了，也许你应该升级一下？

【讨论】：

我认为我们正在使用 Wind River 为 64 位嵌入式系统提供的 gcc 3.x
这就是他想要做的——使用 C++ 风格的 cmets 从 C89 升级到 C89。鉴于他说目标是嵌入式系统，无论如何它不太可能具有符合 C99 的编译器。甚至 GCC 也没有实现 C99。
其实是gcc 2.9！！
如果代码只需要在 2.9+ 版本的 gcc 上编译，那么使用 -ansi 标志没有多大意义。这会阻止您使用其他 C89 实现可能缺少的东西，但如果这不是必需的，那么请考虑使用默认模式 -std=g89，它确实允许 //.

【解决方案2】：

您可以使用 -lang-c-c++-cmets 预处理器来同时拥有 ANSI 模式和 C++ 样式的 cmets。

gcc -Wp,-lang-c-c++-comments -c source.c

【讨论】：

那是因为它实际上是一个预处理器标志，所以你可以像这样调用它：gcc -Wp,-lang-c-c++-cmets——而不是直接在命令行上。但是，如果您真的想要 ansi 可移植性，那么您不应该使用 c++ 样式的 cmets... :)
我认为你的答案是明确的。
我相信这不再受支持。我无法让它在 Mac 或 Linux 上的 GCC 4.2 或 4.4 中工作。我只能在 GCC 的 CPP 手册中找到这个参考（回到 2.9 版）“注意：以前版本的 cpp 接受了一个-lang 选项，它选择了语言和标准一致性级别。这个选项已被删除，因为它冲突使用-l 选项。”我找不到替代品。

【解决方案3】：

在 gcc 的最新版本中，-ansi 被记录为与 -std=c89 相同。新的注释语法仅适用于 C99 标准，因此-std=c99 将允许它。

还有-std=gnu89，它与-std=c89 相同，但允许所有 gcc 扩展（包括 C++ 风格的注释语法，这是一个早在被添加到标准之前的 GNU 扩展）。

还可以查看-pedantic 标志，它可以为您提供一些有用的警告。

参考资料：

【讨论】：

-std=gnu89 可能是 OP 的最佳选择，-std=c99 有其他可能不理想的后果。
-std=gnu89 为我工作，我也在寻找主要是 ansi 语义的增强 cmets。
docs 表示 -ansi 选项等效于 -std=c90，而不是 c89（只是为了“正确”，即使这两个似乎又是同义词？）

【解决方案4】：

如果你想使用 C++ 风格的 cmets 仅仅是因为你想注释掉块，并且对嵌套 /* ... */ 感到头疼，你可以使用这种技术：

#if 0
... code ...
#endif

实际上也可以完成这项工作。

【讨论】：

我的回答有什么问题吗？如果您投反对票，请发表评论。不能嵌套 C-Style cmets，C++ style cmets 在 C++89 中无效。如果您想注释掉 code，这个#if 0 几乎是唯一干净利落的方法。
这是解决这个问题的最佳方法，恕我直言。
这没有回答问题。它只会避免它。
@thomas 但我怀疑问题的真正问题是注释掉代码。因此我回答了。我的回答回避了这个问题，因为它试图从根本上解决假定的问题，这是优越的。
@JohannesSchaub-litb 这样一来，您的答案并不能回答每个人都点击此链接想要解决的问题，而且不那么普遍。所以，不，它并不优越。它对 OP 有帮助，但对大多数稍后单击该链接的人没有帮助。这就是 StackOverflow 的全部意义所在。

【解决方案5】：

如果您仅使用-ansi 来检查兼容性，那么最简单的方法可能是准备一个脚本或makefile 目标，将完整的源代码树复制到“ansi”文件夹中，同时修补// cmets。在伪bash中：

SRC=main.c blip.c blip.h
cp makefile ansi-src/
for F in $SRC do
# does not handle // in string literals or /**/ comments!
sed 's/\/\/.*//g' < $F >ansi-src/$F
done
cd ansi-src
make CFLAGS=-ansi

如果您的 SCC 支持，也可以将其制成一个提交挂钩，在每次提交后以 ANSI 模式在专用机器上自动构建代码，并通过邮件向您发送有关它的报告。

【讨论】：

在修补源代码时请注意尾随反斜杠。

【解决方案6】：

恐怕编写某种评论重写实用程序（正如 Luther Blissett 所建议的那样）可能是您在这里唯一的选择。在现代版本的 gcc 中，似乎没有任何类型的编译器标志或 CLI 选项可以在使用 -ansi 或 -std=c89 时启用 C++ 样式的 cmets。

你也许可以通过从不同的角度接近它来获得你想要的东西。您也许可以使用 -std=c99 进行编译并使用编译器标志来禁用您不想要的 C99 特定扩展（不知道为什么您需要符合 ANSI 的更多信息，我不能推荐特定的标志）。

【讨论】：

【解决方案7】：

您可以自动构建一个去除 cmets 的源代码副本，并在您的程序中使用它。

例如this 看起来很有希望

【讨论】：