O GCC está morrendo sem suporte de threads no Windows? [fechadas]

Eu preciso de uma opinião. O GCC sempre foi um compilador muito bom, mas recentemente está perdendo "apelo". Acabei de descobrir que no Windows GCC não há std::threadsuporte, forçando os usuários do Windows a usar outro compilador porque o recurso mais interessante ainda está faltando.

Mas por que realmente o GCC ainda não tem suporte para threads no Windows? Problemas de licença? Incompatibilidades ABI? (Bem, já existem várias bibliotecas de plataforma cruzada usando multithreading: boost, POCO, SDL, wxwidgets etc. Não seria simples usar o código já existente e licenciado pelo MIT / libpng para atender a esse buraco, em vez de enviar versões do GCC sem suporte de thread?)

Recentemente, observando comparações de compiladores, o GCC tem o suporte mais amplo para os recursos do C ++ 11 em relação a outros compiladores, exceto pelo fato de que no Windows isso não é verdade porque ainda não temos atômicos, mutexes e threads: /

Gostaria de saber mais sobre esse tópico, mas a única coisa que posso encontrar são pessoas pedindo ajuda porque:

"thread" não existe no namespace std

Observando o rastreamento de tickets e discussões por correio do GCC / TDM-GCC, houve pedidos de suporte de encadeamento desde 2009. É possível que, após 4 anos, ainda não haja solução? O que realmente está acontecendo?

Eu entendi que o GCC está desvalorizando porque as pessoas que o mantêm se tornaram um pouco arrogantes, e agora que o LLVM está aqui (e é muito bom), as pessoas estão votando com os pés.

Slashdot discutiu sobre o novo suporte do LLVM para C ++ 11 . _merlin diz:

Ah, eu não acho que alguém pense que é mau, apenas que é puro interesse próprio, e não generosidade. A popularidade fenomenal do GCC levou seus mantenedores a crescer egos maciços e a se comportar como um total [ * *** ]. Os bugs são introduzidos mais rapidamente do que a Red Hat e a Apple pode receber correções para eles serem aceitos, e eles têm o hábito desagradável de não olhar para os relatórios de bugs e depois fechá-los devido à inatividade sem realmente corrigi-los

que concorda com sua observação sobre o atraso de quatro anos.

A popularidade e usabilidade do GCC não são questionáveis.

• O GCC ainda é um ótimo compilador e mais amplamente usado.
• O GCC suporta linguagens para as quais o clang não visa, como Java, Ada, FORTRAN etc.
• O GCC suporta mais destinos que o LLVM.
• O GCC oferece suporte ao C ++ 11

Em https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads, o mingw build em http://code.google.com/p/mingw-builds/downloads/list suporta threads .

Mas uma consideração importante é a Licença.

• O GCC é licenciado sob a licença GPL. O clang usa uma licença BSD, que permite que ela seja incorporada em software que não é licenciado pela GPL.
• O principal motivo para mudar do GCC para o Clang é a incompatibilidade da licença GPL v3 do GCC com os objetivos do projeto FreeBSD.

O FreeBSD tem uma relação desconfortável com a GPL. Os defensores da licença BSD acreditam que o software verdadeiramente livre não tem restrições de uso. Os advogados da GPL acreditam que são necessárias restrições para proteger a liberdade de software e, especificamente, que a capacidade de criar software não livre a partir de software livre é uma forma injusta de poder, e não de liberdade. O projeto FreeBSD, sempre que possível, tenta evitar o uso do GPL (Para detalhes https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Outras considerações importantes

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

• Os ASTs e o design do Clang devem ser facilmente compreendidos por qualquer pessoa que esteja familiarizada com os idiomas envolvidos e que tenha um entendimento básico de como um compilador funciona. O GCC possui uma base de código muito antiga que apresenta uma curva de aprendizado acentuada para novos desenvolvedores.
• O Clang foi projetado como uma API desde o início, permitindo que seja reutilizado por ferramentas de análise de origem, refatoração, IDEs (etc), bem como para geração de código. O GCC é construído como um compilador estático monolítico, o que torna extremamente difícil o uso como uma API e a integração com outras ferramentas. Além disso, seu design histórico e política atual dificultam a dissociação do front-end do restante do compilador.
• Várias decisões de design do GCC tornam muito difícil a reutilização: seu sistema de criação é difícil de modificar, você não pode vincular vários destinos em um binário, não pode vincular vários front-ends em um binário, ele usa um coletor de lixo personalizado, usa variáveis ​​globais extensivamente, não é reentrante ou multiencadeado, etc. Clang não apresenta nenhum desses problemas.
• Para cada token, o clang rastreia informações sobre onde foi gravado e onde foi finalmente expandido se estivesse envolvido em uma macro. O GCC não rastreia informações sobre instanciações de macro ao analisar o código-fonte. Isso dificulta o trabalho das ferramentas de reescrita de código-fonte (por exemplo, para refatoração) na presença de macros (mesmo simples).
• O Clang não simplifica implicitamente o código, pois o analisa como o GCC. Isso causa muitos problemas para as ferramentas de análise de origem: como um exemplo simples, se você escrever "xx" em seu código-fonte, o GCC AST conterá "0", sem mencionar 'x'. Isso é extremamente ruim para uma ferramenta de refatoração que deseja renomear 'x'.
• O Clang pode serializar seu AST em disco e lê-lo novamente em outro programa, o que é útil para toda a análise do programa. O GCC não tem isso. O mecanismo PCH do GCC (que é apenas um despejo da imagem da memória do compilador) está relacionado, mas só é arquitetonicamente capaz de ler o despejo no mesmo executável exato como o que o produziu (não é um formato estruturado).
• O clang é muito mais rápido e usa muito menos memória que o GCC.
• O Clang visa fornecer diagnósticos extremamente claros e concisos (mensagens de erro e aviso) e inclui suporte para diagnósticos expressivos. Às vezes, os avisos do GCC são aceitáveis, mas geralmente confusos e não oferecem suporte a diagnósticos expressivos. O Clang também preserva os typedefs nos diagnósticos de forma consistente, mostrando expansões de macro e muitos outros recursos.
• O Clang herda vários recursos do uso do LLVM como back-end, incluindo suporte a uma representação de bytecode para código intermediário, otimizadores conectáveis, suporte à otimização do tempo do link, compilação Just-in-Time, capacidade de vincular vários geradores de código, etc. .
• O suporte de Clang ao C ++ é mais compatível do que o GCC de várias maneiras (por exemplo, pesquisa de nome de duas fases em conformidade).

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

• A vantagem do llvm / clang é seu design modular, para que ele possa ser
  conectado e usado, por exemplo, para criar ferramentas estáticas de análise de código, o que se torna cada vez mais importante ()

De http://clang.debian.net/

• O clang agora está pronto para criar software para produção (para C, C ++ ou Objective-C). Este compilador está fornecendo muito mais avisos e erros interessantes do que o pacote gcc, embora não tenha o mesmo legado que o gcc.

A razão pela qual leva muito tempo é porque é preciso muito trabalho para obter uma base sólida para construir os cabeçalhos. A maneira como o mingw-w64 parece bo é criar uma sólida biblioteca semelhante a pthreads no Windows. Há menos mal-humorado do que introduzir uma dependência no encadeamento nativo da API do Windows.

implementa <thread>o mingw-w64 e os outros cabeçalhos do C ++ 11 em cima de sua própria winpthreadsbiblioteca. Isso deve estar disponível para teste nas distribuições Mingw-builds e rubenvb da cadeia de ferramentas mingw-w64. Eu recomendaria seguir as listas de discussão mingw-w64 se você quiser rastrear onde a maior parte do trabalho no trabalho nativo do Windows GCC é feita.

O Projeto Qt tem uma página wiki detalhando sua recomendação atual e uma visão geral das cadeias de ferramentas do GCC no Windows, consulte esta página wiki do Projeto Qt .