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

Question

我目前使用Visual Studio 2010在Windows上使用C ++进行开发。在C ++ 11正式发布之后，我开始使用MSVC中已有的一些功能。但是，正如预期的那样，绝大多数新变化都不受支持。

我想也许即将推出的Visual Studio版本会添加这些新功能。但是，在阅读this后，看起来很少会发生变化。

所以，我很好奇在Windows而不是MSVC上使用GCC的可行性，因为它似乎已经支持绝大多数C ++ 11。据我所知，这意味着使用MinGW（我还没有看到任何其他本地Windows版本的GCC）。但我对这是否值得尝试有疑问：

• 它可以用作cl.exe的替代品，还是会涉及很多黑客和兼容性问题，以使Visual Studio使用不同的编译器？
• 在我看来，Visual Studio的主要卖点是它的调试器。如果你使用不同的编译器，它仍然可用吗？
• 由于GCC来自* nix世界，并且不是Windows原生的，与使用本机MSVC编译器相比，创建本机Windows应用程序是否存在代码质量问题？ （如果重要的话：我的大多数项目都是游戏。）
• 换句话说，我编译的exe的质量是否会受到使用非Windows原生编译器的影响？

Answer 1

MSVC具有巨大优势，可以使用在Windows下无效的IDE，包括调试器支持。

MinGW的最佳替代方案可能是Code :: Blocks，但介于两者之间，尤其是关于代码完成和调试器。

此外，MSVC允许您使用MinGW不支持的一些专有Microsoft内容（MFC，ATL和其他可能），并使GDI +和DirectX更容易，更简单（尽管可以同时使用MinGW）

Cygwin，如另一篇文章所述，将具有额外的依赖性和可能的​​许可证问题（依赖性是GPL，因此您的程序也必须如此）。 MinGW没有任何此类依赖性或问题。

MinGW还比MSVC编译显着慢（虽然预编译头文件有点帮助）。

尽管如此，GCC / MinGW是一个完全可靠的质量编译器，在我看来，它在生成代码的质量方面优于任何迄今为止的MSVC版本。
对于最新版本的MSVC，这有点不太明显，但仍然可见。特别是对于与SSE，内在函数和内联汇编相关的任何事情，GCC从那时起就完全消除了MSVC（尽管它们正在慢慢追赶）。

GCC中的标准合规性也要好得多，这可能是一把双刃剑（因为它可能意味着你的一些代码不能在更合格的编译器上编译！），就像C ++ 11支持一样

MinGW还可选择支持DW2异常，这些异常与“普通”风格完全不兼容，并在可执行文件中占用更多空间，但从积极的方面来说，它在运行时“实际上是零成本”。

Answer 2

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

切换到MSVC的主要问题是缺乏与MinGW完美集成的良好IDE。 Visual Studio是一个非常强大的工具，并且是Windows上唯一一段时间的播放器。但是，Jetbrains几天前发布了他们的新C ++ IDE CLion的预览版本。

在处理跨平台应用程序时，主要的好处是。在这种情况下，基于GCC的工具链可以使生活更轻松。此外，CLion与CMake紧密集成，与Visual Studio相比，这也是一个很大的优势。因此，在我看来，现在考虑切换到MinGW是值得的。

Answer 3

GCC的C ++ 11支持是非常惊人的（并且与标准一致性相当，现在已经实现了<regex>）。

如果更换编译器，则需要确保可以使用新编译器构建每个依赖项。它们不是可替换的插件（尽管Clang is working on becoming that way）。

GCC是一个很好的编译器，可以生成与MSVC具有几乎相同性能的代码，如果不是更好的话。它虽然缺少一些低级别的Windows特性。

除此之外，回答你的问题：

1. 要让VS使用GCC作为编译器，您几乎需要转向makefile或自定义构建步骤。从命令行编译并使用CMake或类似的东西你会好得多。
2. 您不能将VS调试器用于GCC代码。 GCC输出GDB兼容的调试信息，VS调试格式是专有的，因此该区域不会很快发生任何变化。
3. 代码质量与您想要的一样好。见上文。
4. 不，代码的质量实际上会增加，因为GCC会指出MSVC会隐藏的几个假定的标准扩展。所有自尊的开源项目都可以通过GCC编译。

Answer 4

它不能用作微软编译器的直接替换替代品，因为它有一组完全不同的命令行参数和编译器特定选项。

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

gcc优于cl的一个经常被吹捧的优点是，gcc可以与ccache一起使用，以大幅加速重建或使用其他几台机器作为编译器从属进行构建。

Answer 5

考虑英特尔编译器（或“Composer”，因为他们似乎已经采取了调用它）作为另一种选择。我不太确定C ++ 11支持与MS相比在哪里（当然它有lambda），但它确实与VisualStudio很好地集成（例如，解决方案中的不同项目可以使用Intel或MS编译器）并且也是为了匹配MS编译器命令行选项而做出的一些努力。

Answer 6

GCC和MSVC对C ++使用不同的名称修改约定。由一个编译器编译的C ++ dll不能在用另一个编译器编译的应用程序中使用。我相信这是我们在Windows中看不到更广泛使用gcc的主要原因。

Answer 7

只需使用visualGDB Visual Studio 2017插件即可。它可以使用任何mingw风味。 64/32位分机TDM-GCC-64（posix），SysGCC（mingw 64），MinGw

问题解决....视觉工作室2017 +任何种类的mingw版本 它有Linux，Windows，Android，Raspberry Pi，任何Linux，开发板支持，Clang intelisense ......令人惊叹。 30天试用。

Answer 8

我的拙见，这首先取决于某人是如何开始编写代码的。我已经使用g ++和gcc已有20多年了，但是我之所以继续使用gcc的原因主要是出于许可方面的原因。尽管我也很喜欢它，因为自从我来自DOS时代以来，我就没有很多运行时依赖项或dll与我的东西捆绑在一起，但我仍然喜欢我的东西又小又快。 Windows的gcc带有标准的win32库和通用控件，但是我不得不为可能需要mcf shit正常工作或看起来更好的东西开发自己的win32控件。

尽管gcc可能在Internet上具有强大的支持，但是当涉及Win32内容时，许多人还是依赖于mcf和vc专有内容，因此，人们可能不得不解决自己的问题并在遇到困难时发挥创造力。

我认为这完全与需求和情况有关。如果您只是一个业余爱好者编码人员，并且有时间进行研究，可以创建自己的库和东西，但是您想要一个自80年代末以来就可以使用的可靠编译器，并且免费的gcc声音非常适合这项工作。

但是在行业中，如果您想保持竞争力并参与竞争，那么视觉工作室是必须的。许多硬件制造商宁愿将Visual Studio兼容库捆绑在一起，因为他们的硬件要比某些开源gnu东西更重要。

那是我的两分钱。