GCCはWindowsでスレッドサポートなしで死にますか？[閉まっている]

意見が必要です。GCCは常に非常に優れたコンパイラーでしたが、最近では「魅力」を失いつつあります。私は、Windows GCCにはstd::threadサポートがなく、Windowsユーザーが別のコンパイラーを使用することを強いられていることがわかりました。なぜなら、最もエキサイティングな機能がまだ欠けているからです。

しかし、WindowsでGCCがまだスレッドをサポートしていないのはなぜですか？ライセンスの問題？ABIの非互換性 （まあ、マルチスレッドを使用するクロスプラットフォームライブラリが既にいくつかあります：boost、POCO、SDL、wxwidgetsなど。GCCリリースを出荷する代わりに、既存のMIT / libpngライセンスのコードをこのホールに合うように使用するのは簡単ではないでしょうかスレッドのサポートなし？）

最近、コンパイラの比較を見ると、GCCは他のコンパイラに比べてC ++ 11の機能を最も幅広くサポートしていますが、Windowsではアトミック、ミューテックス、スレッドがまだないため、これは真実ではありません。

このトピックについてもっと知りたいのですが、私が見つけることができる唯一のことは、次の理由で助けを求める人々です：

「スレッド」はstd名前空間に存在しません

GCC / TDM-GCCのチケットトラッキングとメールディスカッションを見ると、2009年からスレッドサポートのリクエストがありました。本当に何が起こっているのですか？

GCCを支持している人々がいくぶんrog慢になったためにGCCが支持を失っていることを理解しました。

Slashdotは、LLVMのC ++ 11の新しいサポートについて議論しました。_merlinより：

ああ、誰もそれを悪だとは思わない、ただ寛大さよりも純粋な自己利益だと思う。GCCの驚異的な人気により、メンテナーは巨大なエゴを成長させ、合計[ * *** ]のように振る舞います。バグはRed Hatよりも早く導入され、Appleはそれらのパッチを承認することができます。バグレポートを確認せず、実際には修正せずに非アクティブなためクローズするという厄介な習慣があります。

これは、4年の遅れについてのあなたの観察と一致しています。

GCCの人気と使いやすさは疑わしいものではありません。

• GCCは依然として優れたコンパイラであり、最も広く使用されています。
• GCCは、Java、Ada、FORTRANなど、clangが対象としていない言語をサポートしています。
• GCCはLLVMよりも多くのターゲットをサポートします。
• GCCはC ++ 11をサポートしています

https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingwのビルドでhttp://code.google.com/p/mingw-builds/downloads/listは スレッドをサポートしています。

しかし、重要な考慮事項はライセンスです。

• GCCはGPLライセンスの下でライセンスされています。clangはBSDライセンスを使用しているため、GPLライセンスのないソフトウェアに埋め込むことができます。
• GCCからClangに切り替える主な理由は、GCCのGPL v3ライセンスとFreeBSDプロジェクトの目標との非互換性です。

FreeBSDはGPLと不安な関係にあります。BSDライセンスの支持者は、真にフリーなソフトウェアには使用制限はないと考えています。GPLの支持者は、ソフトウェアの自由を保護するために制限が必要であり、特に、フリーソフトウェアから非フリーソフトウェアを作成する能力は、自由ではなく権力の不当な形態であると考えています。FreeBSDプロジェクトは、可能な場合、GPLの使用を回避しようとします（詳細については、 https：//unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm）

その他の重要な考慮事項

http://clang.llvm.org/comparison.html#gccから

• ClangのASTと設計は、関連する言語に精通しており、コンパイラの動作方法の基本的な理解を持っている人なら誰でも簡単に理解できることを意図しています。GCCには非常に古いコードベースがあり、新しい開発者に急な学習曲線を示します。
• Clangは当初からAPIとして設計されており、ソース分析ツール、リファクタリング、IDE（など）による再利用、およびコード生成に使用できます。GCCはモノリシックな静的コンパイラとして構築されているため、APIとして使用して他のツールに統合することは非常に困難です。さらに、その歴史的な設計と現在のポリシーにより、フロントエンドを他のコンパイラから切り離すことは困難です。
• GCCのさまざまな設計上の決定により、再利用が非常に困難になります。ビルドシステムの変更が難しく、複数のターゲットを1つのバイナリにリンクできません。複数のフロントエンドを1つのバイナリにリンクできません。カスタムガベージコレクタを使用します。グローバル変数を広範囲に使用し、再入可能またはマルチスレッド化できません。Clangにはこれらの問題はありません。
• clangは、すべてのトークンについて、書き込まれた場所と、マクロに関係する場合に最終的に展開された場所に関する情報を追跡します。GCCは、ソースコードの解析時にマクロのインスタンス化に関する情報を追跡しません。これにより、ソースリライティングツール（リファクタリングなど）が（単純な）マクロが存在する状態で動作することが非常に難しくなります。
• Clangは、GCCのように解析するため、コードを暗黙的に単純化しません。これを行うと、ソース分析ツールに多くの問題が発生します。1つの簡単な例として、ソースコードに「xx」を記述した場合、GCC ASTには「0」が含まれます。これは、「x」の名前を変更するリファクタリングツールにとっては非常に悪いことです。
• Clangは、ASTをディスクにシリアル化し、別のプログラムに読み戻すことができます。これは、プログラム全体の分析に役立ちます。GCCにはこれがありません。GCCのPCHメカニズム（コンパイラメモリイメージの単なるダンプです）は関連していますが、アーキテクチャ上、ダンプを生成したものとまったく同じ実行可能ファイルに読み込むことができます（構造化形式ではありません）。
• ClangはGCCよりもはるかに高速で、使用するメモリもはるかに少ないです。
• Clangは、非常に明確で簡潔な診断（エラーおよび警告メッセージ）を提供することを目的としており、表現力豊かな診断のサポートが含まれています。GCCの警告は受け入れられることもありますが、しばしば混乱を招き、表現力豊かな診断をサポートしません。Clangはまた、診断でtypedefを一貫して保持し、マクロ展開や他の多くの機能を表示します。
• Clangは、LLVMをバックエンドとして使用することで、中間コードのバイトコード表現のサポート、プラグ可能なオプティマイザー、リンク時最適化のサポート、ジャストインタイムコンパイル、複数のコードジェネレーターでのリンク機能など、多くの機能を継承します。 。
• C ++のC ++のサポートは、GCCのサポートよりも多くの点で準拠しています（たとえば、準拠の2フェーズ名の検索）。

http://www.linuxquestions.org/questions/slackware-14/gcc-vs-llvm-931034/から

• llvm / clangの利点はモジュール設計であるため、
  インターフェースを使用して、たとえば静的コード分析ツールを作成するために使用できます。

http://clang.debian.net/から

• clangは本番用のソフトウェア（C、C ++、Objective-Cのいずれか）をビルドする準備ができました。このコンパイラは、gccと同じレガシーを保持していない一方で、gccスイートよりも多くの警告と興味深いエラーを提供しています。

長い時間がかかる理由は、ヘッダーを構築するための強固な基盤を得るために多くの作業が必要だからです。mingw-w64がboのように見える方法は、Windows上で堅固なpthreadsのようなライブラリを構築することです。Windows APIのネイティブスレッドへの依存関係を導入するよりも、アップストリームの不機嫌さは少なくなります。

mingw-w64 <thread>は、独自のwinpthreadsライブラリの上に他のC ++ 11ヘッダーを実装します。これは、Mingw-buildsとrubenvbのmingw-w64ツールチェーンの両方のディストリビューションでのテストに利用できるはずです。ネイティブWindows GCCの作業のほとんどが行われている場所を追跡する場合は、mingw-w64メーリングリストをフォローすることをお勧めします。

Qtプロジェクトには、現在の推奨事項を詳述するWikiページと、Windows上のGCCツールチェーンの概要があります。このQtプロジェクトwikiページを参照してください。