值得在 Windows 上使用 GCC 来取代 MSVC 吗？

我目前使用 VisualStudio2010在 Windows 上用 C + + 进行开发。在 C + + 11正式发布之后，我开始使用 MSVC 已经提供的一些特性。但是，正如预期的那样，绝大多数的新变化都不被支持。

我认为或许即将发布的 Visual Studio 版本会添加这些新特性。然而，在阅读 这个之后，看起来几乎没有什么变化。

因此，我很好奇在 Windows 上使用 GCC 而不是 MSVC 的可行性，因为它似乎已经支持绝大多数的 C + + 11了。据我所知，这意味着使用 MinGW (我还没有见过任何其他 GCC 的本地 Windows 版本)。但我对这种做法是否值得尝试有疑问:

  • 它是否可以作为 cl.exe 的替代品，或者它是否会涉及许多技巧和兼容性问题，以使 Visual Studio 使用不同的编译器？
  • 在我看来，Visual Studio 的主要卖点是它的调试器。如果使用不同的编译器，它还可用吗？
  • 由于 GCC 来自 * nix 世界，而且不是 Windows 本地的，创建本地 Windows 应用程序与使用本地 MSVC 编译器相比，是否存在代码质量问题？(如果有必要的话: 我的大多数项目都是游戏。)
  • 换句话说，我编译的 exe 文件的质量会因为使用非 Windows 本机编译器而受到影响吗？
76274 次浏览
小开

它不能作为微软编译器的直接交换替代品，首先它有一组截然不同的命令行参数和编译器特定选项。

您可以使用 MinGW 或 Cygwin 来编写软件，但是会引入额外的依赖关系(特别是在 Cygwin 的情况下)。

与 cl 相比，gcc 的一个不常被吹捧的优势是，gcc 可以与 ccache 一起使用，从而大大加快重新构建的速度，或者使用其他几台机器作为编译器的从属机器来构建 distcc。

小开

考虑 Intel 编译器(或者“ Composer”，因为他们似乎已经开始调用它了)作为另一种选择。我不太确定它的 C + + 11支持与 MS 相比处于什么位置(当然它有 lambdas) ，但它确实与 VisualStudio 非常好地集成(例如，解决方案中的不同项目可以使用 Intel 或 MS 编译器) ，而且也有一些努力来匹配 MS 编译器命令行选项。

小开

GCC 和 MSVC 对 C + + 使用不同的名称处理约定。由一个编译器编译的 C + + dls 不能用于与另一个编译器编译的应用程序中。我相信这是我们没有看到在窗口中更广泛使用 gcc 的主要原因。

小开

GCC 的 C + + 11支持是相当惊人的(既然已经实现了 <regex>，那么它与标准一致性相当接近)。

如果替换编译器，则需要确保每个依赖项都可以用新编译器构建。它们不是可替代的插件(尽管是 Clang 正在努力成为那样的人)。

GCC 是一个很好的编译器，并且可以产生与 MSVC 性能相当的代码，如果不是更好的话。不过，它缺少一些 Windows 特有的低级特性。

除此之外，回答你们的问题:

  1. 要让 VS 使用 GCC 作为编译器，您几乎需要一直使用 makefile 或自定义构建步骤。您最好从命令行进行编译，并使用 CMake 或类似的工具。
  2. 不能对 GCC 代码使用 VS 调试器。GCC 输出 GDB 兼容的调试信息，并且 VS 调试格式是专有的，因此这一领域不会很快发生任何变化。
  3. 代码质量和您想要的一样好，见上文。
  4. 不，你的代码质量实际上会提高，因为 GCC 会指出一些假定的标准扩展 MSVC 会对你隐藏。所有自重的开源项目都可以用 GCC 编译。
小开
最佳答案

MSVC 有一个巨大的优势，它提供了一个在 Windows 下无与伦比的 IDE，包括对调试器的支持。

对于 MinGW 来说，最好的替代方案可能是 Code: : Block，但是它们之间还有很多空间，特别是在代码完成和调试器方面。

此外，MSVC 允许您使用一些 MinGW 不支持的微软专有软件(MFC、 ATL，可能还有其他一些) ，并使 GDI + 和 DirectX 的使用更加简单和直接(尽管 MinGW 可以同时做到这两点)。

Cygwin，正如在另一篇文章中提到的，将有额外的依赖关系和可能的许可证问题(依赖关系是 GPL，因此您的程序也必须是)。MinGW 没有任何这样的依赖或问题。

MinGW 编译 意义重大的速度也比 MSVC 慢(尽管预编译头部有一点帮助)。

尽管如此，GCC/MinGW 是一个完全可靠的质量编译器，在我看来，它在生成代码的质量方面优于任何迄今为止可用的 MSVC 版本。
这在 MSVC 的最新版本中有些不那么明显，但仍然可见。特别是对于任何与 SSE、内部特性和内联汇编相关的东西，GCC 从那时起就完全消灭了 MSVC (尽管他们正在慢慢赶上)。

标准遵从性在 GCC 中也要好得多，这可能是一把双刃剑(因为这可能意味着您的一些代码不能在更符合标准的编译器上编译!)以及 C + + 11支持。

MinGW 还可以选择支持 DW2异常，这些异常与“正常”风格完全不兼容，并且在可执行文件中占用更多的空间，但积极的一面是在运行时“几乎零成本”。

小开

我想添加一些信息，因为自提出问题以来字段可能已经更改。

从 MSVC 切换出来的主要问题是缺乏一个完美地集成 MinGW 的 IDE。VisualStudio 是一个非常强大的工具，并且在很长一段时间内是 Windows 上唯一的播放器。然而，Jetbrain 几天前发布了他们新的 C + + IDE CLion 的预览版。

在处理跨平台应用程序时，主要的好处是。在这种情况下，基于 GCC 的工具链可以使工作变得更加容易。此外，CLion 与 CMake 的集成非常有限，与 VisualStudio 相比，CMake 也是一个很大的优势。因此，在我看来，现在值得考虑转向 MinGW。

小开

恕我直言，这取决于一个人最初是如何开始编码的。我已经使用 g + + 和 gcc 超过20年了，但我之所以一直使用 gcc 主要是出于许可的原因。虽然我也喜欢它，当我没有一堆运行时依赖或 dll 的捆绑与我的东西，因为我来自 DOS 时代，我仍然喜欢我的东西小和快速。Gcc for windows 带有标准的 win32库和通用控件，但是我必须开发我自己的 win32控件，这些东西可能需要 mcf 狗屎才能正常工作，或者只是为了看起来更好。

虽然 gcc 可能在互联网上有强大的支持，当谈到 win32的东西，许多依赖于 mcf 和风投专有的东西，所以再次，一个人可能不得不围绕自己的问题和创造性的困难时出现。

我觉得这都是需求和环境的问题。如果你只是一个编码爱好者，有时间进行研究，创建自己的库和东西，但你想要一个坚实的编译器，自80年代后期和免费的，gcc 听起来完美的工作。

但在行业视觉工作室是必须的，如果你想要有竞争力，并留在比赛。许多硬件制造商更喜欢捆绑视觉工作室兼容库，因为他们的硬件超过一些开源 gnu 的东西。

这是我的建议。

小开

老实说，C + + 应该用 MSVisualStudio 来处理。如果你想制作跨平台或 Unix 应用程序，使用 GCC。GCC 可以工作，并且可以与 VisualStudio 以外的任何 IDE 一起使用。甚至 VisualStudio 代码也可以使用 GCC。代码: : Block，用于 C/C + + 开发人员的 Eclipse IDE，CLion，Notepad + + ，甚至是我们熟知的很好的 ol’工具，Notepad 可以与 GCC 一起工作。最后，在一台磁盘空间较小的 PC 上，安装 Visual Studio 的“用 C + + 进行桌面开发”大约需要5GB 的空间，如果需要的话。这就是海湾合作委员会重创 MSVC 的地方。它有原生 C 支持。MSVC 可以编译 C 语言，但需要进行大量的微调。最终能够编译需要花费大量的时间和精力。誓不低头 (无线电视剧)

如果 MSVC 成功了，那就是成功了! 如果 MSVC 不成功了，那就是成功了。

如果 GCC 安装了，它就能正常工作，如果不能正常工作，那就是 IDE 的问题了。

海湾合作委员会是给那些不介意花4个小时在电脑前让它正常工作的人准备的。MSVC 是为那些不关心 C 语言的人准备的，他们希望在安装的时候不要到处乱翻。


提交答案