GCC sta morendo senza thread supportati su Windows? [chiuso]

Ho bisogno di un po 'di opinione. GCC è sempre stato un ottimo compilatore, ma recentemente sta perdendo "fascino". Ho appena scoperto che su Windows GCC non ha std::threadsupporto, costringendo gli utenti di Windows a utilizzare un altro compilatore perché manca ancora la funzionalità più interessante.

Ma perché GCC non ha ancora il supporto per i thread in Windows? Problemi di licenza? Incompatibilità ABI? (Bene, ci sono già diverse librerie multipiattaforma che usano il multithreading: boost, POCO, SDL, wxwidgets, ecc. Non sarebbe semplice usare codice già esistente e con licenza MIT / libpng per adattarsi a questo buco invece di spedire le versioni GCC senza supporto thread?)

Di recente, guardando i confronti dei compilatori, GCC ha il più ampio supporto per le funzionalità C ++ 11 rispetto ad altri compilatori, tranne per il fatto che su Windows questo non è vero perché mancano ancora atomici, mutex e thread: /

Mi piacerebbe saperne di più su questo argomento, ma l'unica cosa che posso trovare sono le persone che chiedono aiuto perché:

"thread" non esiste nello spazio dei nomi std

Guardando il monitoraggio dei biglietti e le discussioni via e-mail di GCC / TDM-GCC, ci sono state richieste di supporto per le discussioni dal 2009. Possibile che dopo 4 anni non ci sia ancora soluzione? Cosa sta succedendo davvero?

Ho capito che GCC sta perdendo favore perché le persone che lo mantengono sono diventate in qualche modo arroganti, e ora che LLVM è qui (ed è molto bravo) le persone votano con i piedi.

Slashdot ha discusso del nuovo supporto di LLVM per C ++ 11 . _merlin dice:

Oh, non penso che nessuno pensi che sia malvagio, solo che è puro interesse personale piuttosto che generosità. La fenomenale popolarità di GCC ha portato i suoi manutentori a crescere ego enormi e comportarsi come un totale [ * *** ]. I bug vengono introdotti più rapidamente di Red Hat e Apple può far accettare le patch per loro, e hanno la brutta abitudine di non guardare le segnalazioni di bug, quindi di chiuderle a causa dell'inattività senza risolverle

che si inserisce con la tua osservazione sul ritardo di 4 anni.

La popolarità e l'usabilità di GCC non sono discutibili.

• GCC è ancora un ottimo compilatore e il più utilizzato.
• GCC supporta i linguaggi a cui non è destinato il clang, come Java, Ada, FORTRAN, ecc.
• GCC supporta più target di LLVM.
• GCC supporta C ++ 11

Da https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build su http://code.google.com/p/mingw-builds/downloads/list supporta thread .

Ma una considerazione importante è la Licenza.

• GCC è concesso in licenza con licenza GPL. clang usa una licenza BSD, che gli consente di essere incorporato in un software che non ha la licenza GPL.
• Il motivo principale per passare da GCC a Clang è l'incompatibilità della licenza GPL v3 di GCC con gli obiettivi del progetto FreeBSD.

FreeBSD ha una relazione difficile con la GPL. I sostenitori della licenza BSD ritengono che il software veramente gratuito non abbia restrizioni d'uso. I sostenitori della GPL ritengono che siano necessarie restrizioni al fine di proteggere la libertà del software, e in particolare che la capacità di creare software non libero dal software libero è una forma ingiusta di potere piuttosto che una libertà. Il progetto FreeBSD, ove possibile, cerca di evitare l'uso della GPL (per i dettagli https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Altre considerazioni importanti

Da http://clang.llvm.org/comparison.html#gcc

• Gli AST e il design di Clang sono concepiti per essere facilmente comprensibili da chiunque abbia familiarità con le lingue coinvolte e abbia una conoscenza di base di come funziona un compilatore. GCC ha una base di codice molto antica che presenta una ripida curva di apprendimento per i nuovi sviluppatori.
• Clang è progettato come un'API sin dal suo inizio, consentendone il riutilizzo da strumenti di analisi della sorgente, refactoring, IDE (ecc.) E anche per la generazione di codice. GCC è costruito come un compilatore statico monolitico, il che rende estremamente difficile l'utilizzo come API e l'integrazione in altri strumenti. Inoltre, il suo design storico e l'attuale politica rendono difficile il disaccoppiamento del front-end dal resto del compilatore.
• Diverse decisioni di progettazione GCC rendono molto difficile il riutilizzo: il suo sistema di compilazione è difficile da modificare, non è possibile collegare più target in un binario, non è possibile collegare più front-end in un binario, utilizza un garbage collector personalizzato, utilizza ampiamente le variabili globali, non è rientrante o multi-thread, ecc. Clang non presenta nessuno di questi problemi.
• Per ogni token, il clang tiene traccia delle informazioni su dove è stato scritto e dove è stato infine espanso se fosse coinvolto in una macro. GCC non tiene traccia delle informazioni sulle istanze macro durante l'analisi del codice sorgente. Ciò rende molto difficile il funzionamento degli strumenti di riscrittura dei sorgenti (ad es. Per il refactoring) in presenza di macro (anche semplici).
• Clang non semplifica implicitamente il codice in quanto lo analizza come GCC. Ciò causa molti problemi agli strumenti di analisi del codice sorgente: come semplice esempio, se scrivi "xx" nel tuo codice sorgente, GCC AST conterrà "0", senza menzionare "x". Questo è estremamente negativo per uno strumento di refactoring che vuole rinominare 'x'.
• Clang può serializzare il suo AST su disco e rileggerlo in un altro programma, utile per l'analisi dell'intero programma. GCC non ha questo. Il meccanismo PCH di GCC (che è solo un dump dell'immagine della memoria del compilatore) è correlato, ma è architettonicamente in grado di rileggere il dump esattamente nello stesso eseguibile di quello che lo ha prodotto (non è un formato strutturato).
• Clang è molto più veloce e utilizza molta meno memoria di GCC.
• Clang mira a fornire una diagnostica estremamente chiara e concisa (messaggi di errore e di avviso) e include il supporto per la diagnostica espressiva. Gli avvisi di GCC sono talvolta accettabili, ma spesso sono confusi e non supportano la diagnostica espressiva. Clang conserva costantemente i typedef nella diagnostica, mostrando espansioni di macro e molte altre funzionalità.
• Clang eredita una serie di funzionalità dal suo uso di LLVM come back-end, incluso il supporto per una rappresentazione bytecode per codice intermedio, ottimizzatori collegabili, supporto per l'ottimizzazione del tempo di collegamento, compilazione Just-In-Time, capacità di collegamento in più generatori di codice, ecc. .
• Il supporto di Clang per C ++ è più conforme di GCC in molti modi (ad es. Ricerca di nomi a due fasi conforme).

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

• Il vantaggio di llvm / clang è il suo design modulare, quindi può essere
  interfacciato e utilizzato ad esempio per creare strumenti di analisi del codice statico, ciò che diventa sempre più importante ()

Da http://clang.debian.net/

• clang è ora pronto per creare software per la produzione (per C, C ++ o Objective-C). Questo compilatore fornisce molti più avvertimenti ed errori interessanti rispetto alla suite gcc mentre non ha lo stesso lascito di gcc.

Il motivo per cui ci vuole molto tempo è perché ci vuole molto lavoro per ottenere una solida base su cui costruire le intestazioni. Il modo in cui mingw-w64 sembra bo è quello di costruire una solida libreria simile a pthreads su Windows. C'è meno scontrosità a monte rispetto a quella di introdurre una dipendenza dal thread nativo dell'API di Windows.

mingw-w64 implementa <thread>e le altre intestazioni C ++ 11 in cima alla propria winpthreadslibreria. Questo dovrebbe essere disponibile per i test in Mingw-builds e nelle distribuzioni rubenvb della toolchain mingw-w64. Vorrei raccomandare di seguire le mailing list mingw-w64 se si desidera tenere traccia di dove viene eseguita la maggior parte del lavoro su GCC nativo di Windows.

Il progetto Qt ha una pagina wiki che descrive in dettaglio la loro attuale raccomandazione e una visione d'insieme delle toolchain GCC su Windows, vedi questa pagina wiki del progetto Qt .