GCC sta morendo senza supporto fili su Windows? [chiuso]

Ho capito che il GCC sta cadendo in disgrazia perché le persone che lo mantengono sono diventate alquanto arroganti, e ora che LLVM è qui (ed è molto buono) la gente vota con i piedi.

Slashdot ha parlato di Il nuovo supporto di LLVM per C ++ 11 . _merlin dice:

Oh I don't think anyone thinks it's evil, just that it's pure self-interest rather than generosity. GCC's phenomenal popularity has led to its maintainers growing massive egos and behaving like total [****]. Bugs are introduced faster than Red Hat and Apple can get patches for them accepted, and they have a nasty habit of not looking at bug reports, then closing them due to inactivity without actually fixing them

che rintocca 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ù usato.
• GCC supporta le lingue a cui clang non mira, come Java, Ada, FORTRAN, ecc.
• GCC supporta più target di LLVM.
• GCC supporta C ++ 11

From https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build at http://code.google.com/p/mingw-builds/downloads/list supports threads.

Ma la considerazione più importante è la licenza.

• GCC è concesso in licenza con licenza GPL. clang utilizza una licenza BSD, che consente di incorporarla in software non con licenza GPL.
• La ragione principale per passare da GCC a Clang è l'incompatibilità della licenza GPL v3 di GCC con gli obiettivi del progetto FreeBSD.

FreeBSD has an uneasy relationship with the GPL. BSD-license advocates believe that truly free software has no usage restrictions. GPL advocates believe that restrictions are necessary in order to protect software freedom, and specifically that the ability to create non-free software from free software is an unjust form of power rather than a freedom. The FreeBSD project, where possible, tries to avoid the use of the GPL (For details https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang-llvm)

Altre considerazioni importanti

Dal link

• Gli AST e il design di Clang sono concepiti per essere facilmente comprensibili da chiunque abbia familiarità con le lingue coinvolte e chi abbia un comprensione di base di come funziona un compilatore. GCC ha un molto vecchio base di codice che presenta una curva di apprendimento ripida per i nuovi sviluppatori.
• Clang è progettato come API sin dal suo inizio, permettendo così di essere riutilizzato da strumenti di analisi dei sorgenti, refactoring, IDE (ecc.) e per la generazione del 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 la politica attuale rende difficile disaccoppiare il front-end dal resto del compilatore.
• Diverse decisioni di progettazione GCC rendono molto difficile il riutilizzo: il suo il sistema di compilazione è difficile da modificare, non è possibile collegare più destinazioni in un binario, non è possibile collegare più front-end in un binario, utilizza un garbage collector personalizzato, utilizza variabili globali estensivamente, non è rientranti o multi-threadable, ecc. Clang ha nessuno di questi problemi.
• Per ogni token, clang tiene traccia delle informazioni su dove è stato scritto e dove infine è stato espanso in se è stato coinvolto in a macro. GCC non tiene traccia delle informazioni sulle istanziazioni delle macro quando analizzando il codice sorgente. Questo rende molto difficile la fonte strumenti di riscrittura (ad esempio per il refactoring) per lavorare in presenza di (anche semplice) macro.
• Clang non semplifica implicitamente il codice mentre lo analizza come GCC lo fa. Ciò causa molti problemi agli strumenti di analisi dei sorgenti: come uno semplice esempio, se scrivi "x-x" nel tuo codice sorgente, GCC AST conterrà "0", senza menzione di "x". Questo è estremamente negativo per a strumento di refactoring che vuole rinominare 'x'.
• Clang può serializzare la sua AST su disco e leggerla in un'altra programma, che è utile per l'intera analisi del programma. GCC no avere questo Meccanismo PCH di GCC (che è solo un dump del compilatore immagine di memoria) è correlata, ma è architettonicamente in grado di leggere solo la discarica nello stesso identico eseguibile di quello che 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 (errore e messaggi di avvertimento), e include il supporto per espressivo diagnostica. Gli avvertimenti del GCC sono a volte accettabili, ma sono spesso confuso e non supporta la diagnostica espressiva. Clang anche conserva costantemente i typedef in diagnostica, mostrando macro espansioni e molte altre funzionalità.
• Clang eredita una serie di funzioni dal suo uso di LLVM come a back-end, incluso il supporto per una rappresentazione bytecode per codice intermedio, ottimizzatori collegabili, ottimizzazione del tempo di collegamento supporto, compilazione Just-In-Time, possibilità di collegamento in più codice generatori, ecc.
• Il supporto di Clang per C ++ è più conforme di GCC in molti modi (ad esempio, la ricerca di un nome a due fasi conforme).

Da     link

• 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 link

• clang è ora pronto per creare software per la produzione (sia per C, C ++ o Objective-C). Questo compilatore sta fornendo molti più avvisi e errori interessanti rispetto alla suite gcc pur non portando lo stesso legacy come gcc.

Il motivo per cui ci vuole un sacco di tempo è perché ci vuole molto lavoro per avere una base solida per costruire le intestazioni in cima. Il modo in cui mingw-w64 sembra essere quello di costruire una solida libreria tipo pthreads su Windows. C'è meno grumpiness upstream rispetto a quello che introduce una dipendenza dal threading nativo dell'API di Windows.

mingw-w64 implementa <thread> e le altre intestazioni C ++ 11 in cima alla propria libreria winpthreads . Questo dovrebbe essere disponibile per il test sia in Mingw-builds sia nelle distribuzioni di rubenvb della toolchain mingw-w64. Raccomanderei di seguire le mailing list mingw-w64 se si desidera tenere traccia di dove è svolto gran parte del lavoro sul lavoro nativo di GCC di Windows.

Il progetto Qt ha una pagina wiki che descrive dettagliatamente la loro raccomandazione corrente e una vista oltre delle toolchain GCC su windows, vedi questa pagina wiki Qt Project .