我现在在Windows上使用Visual Studio 2010开发C++。在正式宣布C++ 11之后,我已经开始使用一些已经在MSVC中可用的特性。但是,正如预期的那样,绝大多数的新变化都不受支持。
我想也许即将到来的Visual Studio版本会添加这些新功能。然而,在阅读了这篇文章之后,看起来几乎没有什么变化。
因此,我很好奇在Windows上使用GCC而不是MSVC的可行性,因为它似乎已经支持了绝大多数C++ 11。据我所知,这意味着使用mingw(我没有看到任何其他本地的gcc Windows版本)。但我有疑问,这是否值得尝试:
- 它是否可以作为cl.exe的嵌入式替代品,或者它是否会涉及许多黑客和兼容性问题,以使Visual Studio使用不同的编译器?
- 在我看来,Visual Studio的主要卖点是它是调试器。如果使用不同的编译器,它是否仍然可用?
- 由于gcc来自*nix世界,而不是Windows的本机版本,与使用本机MSVC编译器相比,创建本机Windows应用程序是否存在代码质量问题?(如果重要的话:我的大多数项目都是游戏。)
- 换句话说,使用非Windows本机编译器会影响编译后的exe的质量吗?
- 您可能会发现等待Visual Studio 11也是一个需要考虑的选项。
- 如果你想使用mingw,你也应该考虑使用不同的ide。
- @ VCSJONS:我链接的站点是关于VisualStudio 11中的C++ 11更改。我没有印象,所以这篇文章。
- @奈鲁啊,明白了。
- @vcsjones-fwiw,有迹象表明,微软将以正常的vs发布时间表在带外发布编译器更新。当然,这是微软,所以只有时间才能证明。
- gcc生成的代码质量基本上是msvc的许多倍。后者只是不知道有多少优化:)
- @君士坦提乌斯有什么证明吗?这肯定会增加我放弃MSVC的动机。
- @nairo linux kongres.org/2009/slides/…如果你浏览这些幻灯片,你会发现很多MSVC案例不够聪明:)
- 在参加派对的时候,我避开了VS2012,直接进入了VS2013,与VS2010相比,这真是太不可思议了。我只有一个用bool初始化atomic_bool的问题,还有一些奇怪的窗口问题,您通常可以解决。如果你关心写正确的C++,那么你会想要这个。
MSVC有一个巨大的优势,那就是它在Windows下拥有一个无与伦比的IDE,包括调试器支持。
对于mingw,最好的选择可能是code::blocks,但是两者之间存在着一些世界,特别是关于代码完成和调试器。
此外,MSVC还允许您使用Mingw不支持的一些专有的Microsoft产品(MFC、ATL,以及可能的其他产品),并使使用GDI+和DirectX变得更容易和更简单(尽管可以同时使用Mingw)。
正如另一篇文章中提到的,Cygwin将具有额外的依赖关系和可能的许可证问题(依赖关系是GPL,所以您的程序也必须是GPL)。明威没有这种依赖或问题。
mingw的编译速度也明显低于msvc(尽管预编译头有点帮助)。
尽管如此,gcc/mingw是一个完全可靠的质量编译器,在我看来,它在生成代码的质量方面优于任何现有的MSVC版本。这在最新版本的MSVC中不太明显,但仍然可见。特别是对于与SSE、Intrinsics和内联汇编相关的任何内容,GCC从那时起就完全支持MSVC(尽管它们正在慢慢跟上)。
GCC中的标准遵从性也要好得多,这可能是一把双刃剑(因为这可能意味着某些代码无法在更符合标准的编译器上编译!),就像C++ 11的支持一样。
mingw还可选地支持dw2异常,这些异常与"正常"风格完全不兼容,并在可执行文件中占用更多空间,但在积极方面,运行时"几乎为零成本"。
- 这就是我一直以来的印象…由此产生的应用将是伟大的,但与MSVC相比,开发过程将大大减少。让我想知道Linux开发人员是如何管理的!
- 我有一段时间没有签入,所以可能是错的,但上次我检查代码::块时并没有真正说服我。我个人建议要么EclipseCDT,要么使用太多的资源qtcreator进行mingw开发。
- Eclipse当然有更好的代码完成能力,但它的重量大约是它的20倍,启动时间大约是它的10倍,等等。它在200万个构建选项中的功能可能也更强大,尽管就个人而言,这让我感到困惑,而不是乐于助人。我想这是个人品味的问题(另外,我可能有点不公平地偏向于code::blocks)。但可以肯定的是,日食可能是一个可行的选择。
- 这很有趣;在我尝试过的几个项目中,mingw编译得更快,结果代码运行得更快——尽管使用msc对代码进行了分析和优化(即针对msc而不是gcc进行了调优)。
- @eamonnerbonne:除非有人作弊(例如,使用带有mingw的预编译头文件,而不使用msvc),否则mingw/gcc的编译速度比几乎任何竞争对手都要慢(高达2倍),特别是在优化方面。幸运的是,除非依赖性很糟糕,否则这不是真正的问题。原因既在于实际的编译器速度,也在于工具链有很多分支(有时每个源代码有4-5个分支),这在类似Unix的系统下很好,但在Windows下却相当具有破坏性。另外,GNUld的性能也很糟糕。关于应用程序性能,我完全同意…
- …Mingw一致地生成了比我认识的任何竞争对手(包括MSVC)运行速度更快的更好的代码(这是指真正的代码,而不是在基准测试上作弊)。
- @Damon:我在mscv上使用预编译头,而不是mingw上;因为它们更容易为msc设置,而且因为;嗯,msc的减速很烦人,所以我花了更多的精力让它快速编译。我使用了很多来自Boost和Eigen的重型模板代码,所以MSC可能无法有效地处理这些问题;但无论如何,我都会尝试对其进行切片;使用MSC编译只需要更长的时间(我不认为它们需要相当长的2倍的时间,但就在这一点上)。
- 我在Windows上使用EclipseCDT和MingW,并且我发现它的代码导航/完成功能与MSVC相当,如果不比MSVC更好的话。
- 好了,伙计们,很抱歉打断这场长时间的讨论。通过经验发现这些新事物:(1)NeBeBee比Eclipse CDT更轻,用于用Visu/MiW64 W64进行C++编译。(2)MIWW W64(和调试器)现在对大多数事情都很好,因此击败MVC C++快件(只为x86编译)。(3)Mingw代码更精简、更简洁,因此速度更快,即使在MVC中试图切断多余的猪油。(4)NETBeaS C/C++的新OpenCL插件工作很好,但在MVC中建立OpenCL支持仍然是一件痛苦的事情。-希望这能帮助所有的C编码人员。
- P.S.(5)最近尝试从一个管理的C.Y.DLL(MVCYL)产生的非管理DLL中调用C/C++函数,并获得极大的成功和乐趣。
- @Gregkramida:关于第(4)点——使用WDK可以帮助您动态链接到操作系统中包含的CRT(即,无需将其与程序一起分发),减少FAT。
- 这里有一些编译时速度比较slashdot.org/topic/cloud/…
- @奈鲁:作为一个Linux开发人员,我只为自己说话:我不使用IDE。命令行工具是强大的,与C语言或Java语言不同,C++不是为了IDE的使用而构建的。
- @奈鲁让我想知道Linux开发人员是如何管理的!-Linux开发人员通常使用某种vim/emacs。当你觉得舒服的时候,这是件好事。还有人已经提到过作为ide qtcreator。最近我通过virtualbox使用了vs2010,我想知道它是如何被破坏的。虽然对于移动,我找到了vsvim插件,但它的调试器仍然比gdb差得多。也就是说,我不能在Visual Studio中设置断点来在代码中的某个地方设置临时中断,然后继续。另外,我也没能找到一个命令,让break打印一个内存区……很多东西,都不适合发表评论。
- 回答很好,谢谢。
- 型更新:我相信,凭借其现代的设计、丰富的功能和cmake集成,它值得成为"Windows上最好的非MSVC IDE"。它也得到了更积极的维护。
我想添加一些信息,因为该字段可能在问题提出后发生了更改。
从MSVC转换的主要问题是缺少一个完美地与Mingw集成的好的IDE。Visual Studio是一个非常强大的工具,在相当长一段时间内是Windows上唯一的播放器。然而,JeTebug在几天前发布了他们新的C++ IDE CyLee的预览版本。
主要的好处是在跨平台应用程序上工作。在这种情况下,基于GCC的工具链可以使生活更容易。此外,与Visual Studio相比,Clion还与CMake进行了狭隘的集成,这也是一个很大的优势。因此,在我看来,现在就有必要考虑改用明格。
- 型仍然没有一个像MSV一样稳定和支持的好的IDE,而且clion也不在同一个球场上(它充满了bug,用gdb进行调试是一场噩梦)。
GCC的C++ 11支持是非常惊人的(并且与标准一致性相当高,现在已经实现了EDCOX1×0)。
如果替换编译器,则需要确保每个依赖项都可以用新编译器构建。它们并不是用来替代插件的(尽管Clang正在努力做到这一点)。
gcc是一个很好的编译器,它可以生成与msvc性能几乎相同(如果不是更好的话)的代码。但它缺少一些特定于Windows的低级功能。
除此之外,回答您的问题:
要让vs使用gcc作为编译器,您几乎需要一直使用makefiles或自定义构建步骤。您最好从命令行编译并使用cmake或类似的工具。
不能将vs调试器用于gcc代码。GCC输出与gdb兼容的调试信息,而vs调试格式是专有的,因此在该领域不会很快发生任何变化。
代码质量和您想要的一样好。见上文。
不,代码的质量实际上会提高,正如GCC指出的那样,MSVC会对您隐藏一些假定的标准扩展。所有自尊心强的开源项目都可以用gcc编译。
GCC和MSVC使用不同的C++命名规则。由一个编译器编译的C++ DLL不能在与其他编译器编译的应用程序中使用。我认为这是我们没有看到在Windows中更广泛地使用gcc的主要原因。
- 米凯罗比:也许你看不到广泛使用,但请看得更远一点。几乎所有从Linux世界(这里我想的是VLC、ffmpeg、gsl、openoffice、kde…)转移过来的东西都使用mingw(gcc)。上次看到为所有版本的MSVC构建的库是什么时候?因为每个版本,包括sp版本也会破坏abi,所以gcc可以对任何gcc版本使用一个版本(从4.2开始,这是非常老的版本)。我认为MSVC在这里处于劣势。
- @Rebenvb,我没有说它是不普遍的,我说它可能是"更普遍的"。Linux是普遍的,但这并不意味着没有太多的增长空间。我正在考虑使用Visual C++编写的开放源码应用程序的数量不多:Chrome、Firefox、MySQL、PostgreSQL、Brand、Apache等等。事实上,官方的python版本是用msvc编译的,这让我很头疼,而且迫使我使用cygwin。当你说Linux中的任何东西都是用gcc编译的时候,我非常希望你是正确的。
- 啊,是的,我忘了那些半商业的东西。当你想到Mozilla构建系统必须(经过大量修改的MSY)才能用MSVC构建时,这是很有趣的。
- GCC DLL可以与MSVC执行人员一起使用,如果您知道如何使用的话。因为这个原因,外星"C"在这里!GetProcAddress()相同
- 除非你建立了一个C接口来弥补这个差距,所以这句话不适用于C++。这完全改变了应用程序的设计方式。
- DLL主要设计为用作C接口。有一些协议(丑陋的黑客:p)是MSVC用来屏蔽这些东西的。每一个DLL都有"C"出口,即使它被广告为"C++"DLL。msvc dll只是把它破解了。在mingw/gcc中,您可以根据自己的喜好命名C导出。"赌博"C++类方法的方式是不同的,但是有宏,你可以制作一个宏,扩展到一个适当的手工"赌博"存根。
把英特尔编译器(或他们似乎已经习惯称之为"作曲家")作为另一个选项。我不太确定它的C++ 11支持在哪里与MS相比(当然它有lambdas),但是它确实与VisualStudio集成得很好(例如,在一个解决方案中的不同项目可以使用英特尔或MS编译器),并且还做出了一些努力来匹配MS编译器命令行选项。
- 当代码在AMD芯片上执行时,英特尔编译器故意禁用它的许多优化。
- @米凯罗比不是"反托拉斯"之类的吗?记住,M$getting被诉是因为它使Internet Explorer更容易使用,并且没有允许其他浏览器集成到shell中的API/etc,或者类似的东西。
- @蒙托奥-不,这是"一个安全功能",因为英特尔不是AMD的专家,他们不能确定他们的优化是正确的;-)
- @马丁贝克特啊,这是有道理的!如果政府能给他们一些钱,他们也许能再雇佣五个程序员来优化他们最大的竞争对手的芯片…
- @MartinBeckett,英特尔的开发人员不需要成为AMD的专家,就可以知道AMD的SSE指令在那里的行为是一样的。第三方编译器作者在AMD或英特尔芯片上没有内部专业知识,但他们在添加优化方面没有任何困难。
- @Munto,程序员的数量与此无关。同样的优化也适用于AMD芯片。这只是给他们的产品一个竞争优势的问题。
- 我记得这很容易被规避(在编译二进制补丁以删除cpuid检查之后),而且我认为甚至在后来的ICC版本中,由于虚假竞争而被删除。
- @你的意思是一家几乎垄断的技术公司可能在反竞争行为的正当性方面不完全真实?我震惊了
- 有关AMD问题的更多信息,请参阅此问题的链接…stackoverflow.com/questions/839667/…
它不能作为微软编译器的直接交换替代品,首先它有一组截然不同的命令行参数和编译器特定的选项。
您可以使用mingw或cygwin编写软件,但引入额外的依赖项(尤其是在cygwin的情况下)。
gcc相对于cl的一个不常被吹捧的优点是,gcc可以与ccache一起使用,以极大地加快重建或distcc的速度,从而使用其他几台机器作为编译器的从属机器来构建。
只需使用VisualGDB Visual Studio 2017插件。它可以用任何混合的味道。64/32位ext tdm-gcc-64(posix)、sysgcc(mingw 64)、mingw
解决问题……Visual Studio 2017+任何类型的mingw版本它有linux,windows,android,raspberry pi,任何linux,开发板支持,clang intelisense…太神奇了。30天试验。