WindowsでMSVCを置き換えるGCCの価値はありますか？
現在、Visual Studio 2010を使用して、Windows上のC++で開発しています。C++ 11の公式発表後、MSVCで既に利用可能な機能の一部を使用し始めています。しかし、予想どおり、新しい変更の大部分はサポートされていません。
Visual Studioの今後のバージョンでこれらの新機能が追加されると思いました。ただし、 this を読んだ後は、ほとんど変更されないようです。
それで、すでにC++ 11の大部分をサポートしているように見えるため、MSVCではなくWindowsでGCCを使用する可能性に興味があります。私が知る限り、これはMinGWを使用することを意味します（GCCの他のネイティブWindowsバージョンを見たことはありません）。しかし、私はこれが試してみる価値があるかどうかについて質問があります：
- Cl.exeのドロップイン置換として使用できますか、それともVisual Studioで別のコンパイラを使用するために多くのハックや互換性の問題が発生しますか？
- 私の意見では、Visual Studioの主なセールスポイントはデバッガーです。別のコンパイラを使用する場合、それはまだ使用可能ですか？
- GCCは* nixの世界から来ており、Windowsにネイティブではないので、ネイティブのMSVCコンパイラを使用するのではなく、ネイティブのWindowsアプリケーションの作成にコード品質の問題がありますか？ （重要な場合：私のプロジェクトのほとんどはゲームです。）
- 言い換えると、コンパイルされたexeの品質は、非Windowsネイティブコンパイラを使用することで損なわれますか？
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例外もサポートします。これは、「通常の」フレーバーとは完全に互換性がなく、実行可能ファイルのスペースをより多く使用しますが、プラス面は実行時に「実質的にゼロコスト」です。
質問がされてからフィールドが変更された可能性があるため、いくつかの情報を追加します。
MSVCから切り替える主な問題は、MinGWと完全に統合できる優れたIDEが不足していることです。VisualStudioは非常に強力なツールであり、かなり長い間Windowsで唯一のプレーヤーでした。 Jetbrainsは、数日前に新しいC++ IDE CLionのプレビューバージョンをリリースしました。
主な利点は、クロスプラットフォームアプリケーションで作業する場合に得られます。この場合、GCCベースのツールチェーンにより、作業がはるかに簡単になります。さらに、CLionはCMakeと密接に統合されており、Visual Studioと比較して大きなプラスでもあります。したがって、私の意見では、MinGWへの切り替えを検討する価値があります。
GCCのC++ 11のサポートは非常に驚異的です（標準準拠と同等になり、今では<regex>が実装されました）。
コンパイラを置き換える場合、すべての依存関係がその新しいコンパイラで構築できることを確認する必要があります。それらは、代替可能なプラグインにはなりません（ただし、 Clangはそのようになることに取り組んでいます ）。
GCCは優れたコンパイラーであり、MSVCとほぼ同じパフォーマンスのコードを生成できます。ただし、いくつかの低レベルのWindows固有の機能がありません。
これとは別に、あなたの質問に答えるために：
- VSがGCCをコンパイラとして使用できるようにするには、メイクファイルまたはカスタムビルドステップをずっと使用する必要があります。コマンドラインからコンパイルしてCMakeなどを使用する方がはるかに良いでしょう。
- GCCコードにはVSデバッガーを使用できません。 GCCはGDB互換のデバッグ情報を出力し、VSデバッグ形式はプロプライエタリであるため、すぐにその領域で何も変更されません。
- コードの品質は、望みどおりです。上記を参照。
- いいえ、GCCはMSVCがあなたから隠していると思われるいくつかの標準拡張を指摘するので、コードの品質は実際に向上します。すべての自尊心のあるオープンソースプロジェクトは、GCCでコンパイルできます。
別のオプションとして、Intelコンパイラー（または「Composer」と呼んでいるようです）を検討してください。私はそのC++ 11サポートがMS（確かにラムダを持っている）と比較してどこにあるのかあまり知りませんが、VisualStudioと非常にうまく統合します（たとえば、ソリューション内の異なるプロジェクトはIntelまたはMSコンパイラを使用できます）また、MSコンパイラのコマンドラインオプションに一致させるための努力も行われました。
GCCとMSVCは、C++に対して異なる名前マングリング規則を使用します。一方のコンパイラでコンパイルされたC++ dllは、他方のコンパイラでコンパイルされたアプリケーションでは使用できません。これがWindowsでのgccの普及が見られない主な理由だと思います。
Microsoftコンパイラーの直接スワップアウトの代替として使用することはできません。最初は、コマンドライン引数とコンパイラー固有のオプションの大幅に異なるセットがあります。
MinGWまたはCygwinを使用してソフトウェアを作成できますが、追加の依存関係を導入できます（特にcygwinの場合）。
Gccがclより優れていることはよくありませんが、gcacheをccacheと共に使用して再構築を大幅に高速化したり、distccを使用して他の複数のマシンをコンパイラスレーブとして使用してビルドしたりできることがあります。
VisualGDB Visual studio 2017プラグインを使用するだけです。任意のmingwフレーバーを使用できます。 64/32ビットext TDM-GCC-64（posix）、SysGCC（mingw 64）、MinGw
解決された問題.... Visual Studio 2017 +あらゆる種類のmingwバージョンLinux、Windows、Android、Raspberry Pi、任意のLinux、開発ボードサポート、Clang intelisense ...があります。 30日間のトライアル。