在 gcc 和 Visual C++ 中使用“>>”答案

【问题标题】：Using '>>' across gcc and visual c++在 gcc 和 Visual C++ 中使用“>>”
【发布时间】：2010-09-26 08:46:18
【问题描述】：

我们正在编写一个使用 gcc 和 Visual C++ 编译的应用程序。一些团队成员只使用 Visual C++/Windows，而其他人只使用 gcc/linux。由于编译器之间的差异，构建有时会中断。我已经“修复”了几个使用编译器选项来启用/禁用警告导致构建中断的场景，但目前我坚持使用 C++ 模板中使用的“>>”。

Visual Studio 似乎单方面扩展了标准，将“>>”作为模板中的有效表达式包括在内（这仅在提议的 C++0x 中有效）。但是 gcc 不接受这是一个有效的模板。现在我无法在 Visual Studio 中找到禁止“>>”或在 gcc 中允许“>>”的选项。我应该如何进行？

注意：这个问题是关于双尖括号，而不是右移运算符。

【问题讨论】：

标签： c++ visual-c++ gcc

【解决方案1】：

我会将它们分开为 > >。这就是当前标准的要求；它是最正确和可移植的代码。据我所知，如果尖括号彼此相邻，gcc 甚至不会编译。

【讨论】：

是的，我的问题是使用 Visual Studio 的团队成员不介意使用“>>”。这会导致构建中断。
那么你需要执行一个编码标准。 sbi 的建议听起来不错。所有编码人员都需要编写适合所有人的代码。如果他们破坏了构建，他们就做错了！
Visual Studio 还允许不写 typename 来引用依赖于另一个模板的类型。你要去那里做什么？问题很简单，解决方法也很简单。如果您想要可移植性，请使用标准 C++ 而不是编译器扩展。或者决定使用一个真正符合标准的编译器（Comeau 将适合那里）。
您可以建议 VS 开发人员定期使用 MinGW 编译他们的代码并修复出现的错误。
@David, @Matteo 你说的有道理。然而，我们在一个研究环境中工作，不幸的是，与软件开发相反的研究占据了大部分时间。我们时间紧迫。有些程序员是初学者，理想的情况是先简化他们的生活，然后再让其他人复杂化。

【解决方案2】：

GCC 当前 (since version 4.3) 通过以下方式支持此功能：

g++ --std=c++0x -o output file1.cpp file2.cpp ...

您必须明确指定您的源代码是用 C++0x 标准编写的。

【讨论】：

这个问题是 C++0x 是实验性的，即随着标准的发展，一些特性可能会被删除。但这可能是我必须采取的方法。
@Amit Kumar：是的，它是实验性的，但Right angle brackets 功能将永远存在。
但是> > 也将永远继续工作，并且还有一个额外的优势，那就是它现在也可以工作了。为 GCC 启用 C++0x 扩展的问题可能在于这会使 GCC 用户引入 VC 无法处理的代码。对不起，但我不喜欢这个建议。当你在做跨平台的事情时，你需要适应所有平台上可用的和稳定的。 C++1x 不是。
@Amit：功能不会从中删除。它功能齐全，从现在开始，他们所做的唯一项更改是小错误修复和措辞更改。

【解决方案3】：

处理此类问题的方法是让 Automatic Builds 和 Tests 全天候运行，由签入触发。这也称为持续集成。当构建中断或测试失败时，您需要能够查找导致此问题的签入并将矛头指向负责的开发人员。

例如，请参阅 this answer 了解跨平台执行此操作的工具。

【讨论】：

我们有自动构建和指责 Hudson 提供的功能，但只能在 Windows 上运行。希望有一天我能找到时间来实现它，也可以使用 Cygwin/g++ 运行。但编译器错误仍然要好得多。
@Amit：然后看看hudson。我已经看到（或帮助）从头开始设置到在几个小时内运行几次。在我见过的各种 CI 工具中，这是迄今为止最容易设置的，尤其是跨平台。使用 GCC 和 VC 设置（虚拟）构建从机应该非常容易。
正如我所说，我已经在使用 Hudson。跨平台构建工具的链接很有用。谢谢。
@Amit：很抱歉我忽略了你说你已经在使用 hudson。（这就是我在四个孩子拉着我的袖子回答 SO 时得到的结果……）那么你为什么不直接设置一个 GCC 构建从站呢？