¿GCC está muriendo sin compatibilidad con subprocesos en Windows? [cerrado]

Necesito alguna opinión GCC siempre fue un muy buen compilador, pero recientemente está perdiendo "atractivo". Acabo de descubrir que en Windows GCC no tiene std::threadsoporte, lo que obliga a los usuarios de Windows a usar otro compilador porque todavía falta la característica más emocionante.

Pero, ¿por qué realmente GCC todavía no tiene soporte para subprocesos en Windows? ¿Problemas de licencia? Incompatibilidades ABI? (Bueno, ya hay varias bibliotecas multiplataforma que usan subprocesos múltiples: boost, POCO, SDL, wxwidgets, etc. ¿No sería fácil usar un código ya existente y con licencia MIT / libpng para adaptarse a este agujero en lugar de enviar versiones de GCC sin soporte de hilo?)

Recientemente, mirando las comparaciones de compiladores, GCC tiene el soporte más amplio para las características de C ++ 11 con respecto a otros compiladores, excepto por el hecho de que en Windows esto no es cierto porque todavía nos faltan atómicos, mutexes e hilos: /

Me gustaría saber más sobre este tema, pero lo único que puedo encontrar es que las personas soliciten ayuda porque:

"thread" no existe en el espacio de nombres estándar

Mirando el seguimiento de tickets y las discusiones por correo de GCC / TDM-GCC, hubo solicitudes de soporte de hilos desde 2009. ¿Posible que después de 4 años todavía no haya solución? ¿Qué está pasando realmente?

Comprendí que GCC está cayendo en desgracia porque las personas que lo mantienen se han vuelto algo arrogantes, y ahora que LLVM está aquí (y es muy bueno) la gente está votando con los pies.

Slashdot tuvo una discusión sobre el nuevo soporte de LLVM para C ++ 11 . _merlin dice:

Oh, no creo que nadie piense que es malo, solo que es puro interés propio en lugar de generosidad. La popularidad fenomenal de GCC ha llevado a sus mantenedores a crecer egos masivos y comportarse como un total [ * *** ]. Los errores se introducen más rápido que Red Hat y Apple puede aceptar parches para ellos, y tienen el desagradable hábito de no mirar los informes de errores y luego cerrarlos debido a la inactividad sin realmente corregirlos.

lo que interviene con su observación sobre el retraso de 4 años.

La popularidad y usabilidad de GCC no es cuestionable.

• GCC sigue siendo un gran compilador y el más utilizado.
• GCC admite lenguajes a los que no apunta clang, como Java, Ada, FORTRAN, etc.
• GCC admite más objetivos que LLVM.
• GCC es compatible con C ++ 11

Desde https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build en http://code.google.com/p/mingw-builds/downloads/list admite subprocesos .

Pero una consideración importante es la licencia.

• GCC tiene licencia bajo la licencia GPL. clang usa una licencia BSD, que le permite integrarse en un software que no tiene licencia GPL.
• La razón principal para cambiar de GCC a Clang es la incompatibilidad de la licencia GPL v3 de GCC con los objetivos del proyecto FreeBSD.

FreeBSD tiene una relación incómoda con la GPL. Los defensores de la licencia BSD creen que el software verdaderamente libre no tiene restricciones de uso. Los defensores de GPL creen que las restricciones son necesarias para proteger la libertad del software, y específicamente que la capacidad de crear software no libre a partir de software libre es una forma injusta de poder en lugar de una libertad. El proyecto FreeBSD, cuando sea posible, intenta evitar el uso de la GPL (para obtener detalles https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Otras consideraciones importantes

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

• El AST y el diseño de Clang están destinados a ser fácilmente entendibles por cualquiera que esté familiarizado con los idiomas involucrados y que tenga una comprensión básica de cómo funciona un compilador. GCC tiene una base de código muy antigua que presenta una curva de aprendizaje abrupta para los nuevos desarrolladores.
• Clang está diseñado como una API desde su inicio, lo que le permite ser reutilizado por herramientas de análisis de origen, refactorización, IDE (etc.), así como para la generación de código. GCC está construido como un compilador estático monolítico, lo que hace que sea extremadamente difícil usarlo como API e integrarlo en otras herramientas. Además, su diseño histórico y su política actual hace que sea difícil desacoplar el front-end del resto del compilador.
• Varias decisiones de diseño de GCC hacen que sea muy difícil de reutilizar: su sistema de construcción es difícil de modificar, no puede vincular múltiples objetivos en un binario, no puede vincular múltiples front-end en un solo binario, utiliza un recolector de basura personalizado, usa variables globales ampliamente, no es reentrante ni multihilo, etc. Clang no tiene ninguno de estos problemas.
• Para cada token, el sonido metálico rastrea información sobre dónde se escribió y dónde se expandió finalmente si estaba involucrado en una macro. GCC no rastrea la información sobre las instancias de macro cuando analiza el código fuente. Esto hace que sea muy difícil para las herramientas de reescritura de origen (por ejemplo, para refactorizar) trabajar en presencia de macros (incluso simples).
• Clang no simplifica implícitamente el código, ya que lo analiza como lo hace GCC. Hacerlo causa muchos problemas para las herramientas de análisis de origen: como un simple ejemplo, si escribe "xx" en su código fuente, el AST de GCC contendrá "0", sin mencionar 'x'. Esto es extremadamente malo para una herramienta de refactorización que quiere cambiar el nombre de 'x'.
• Clang puede serializar su AST en el disco y volver a leerlo en otro programa, lo cual es útil para el análisis completo del programa. GCC no tiene esto. El mecanismo PCH de GCC (que es solo un volcado de la imagen de memoria del compilador) está relacionado, pero arquitectónicamente solo puede volver a leer el volcado exactamente en el mismo ejecutable que el que lo produjo (no es un formato estructurado).
• Clang es mucho más rápido y usa mucha menos memoria que GCC.
• Clang tiene como objetivo proporcionar diagnósticos extremadamente claros y concisos (mensajes de error y advertencia) e incluye soporte para diagnósticos expresivos. Las advertencias de GCC a veces son aceptables, pero a menudo son confusas y no admite diagnósticos expresivos. Clang también conserva los typedefs en diagnósticos consistentemente, mostrando expansiones macro y muchas otras características.
• Clang hereda una serie de características de su uso de LLVM como back-end, incluido el soporte para una representación de código de bytes para código intermedio, optimizadores conectables, soporte de optimización de tiempo de enlace, compilación Just-In-Time, capacidad de enlace en múltiples generadores de código, etc. .
• El soporte de Clang para C ++ es más compatible que el de GCC en muchos aspectos (por ejemplo, búsqueda de nombres de dos fases conforme).

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

• La ventaja de llvm / clang es su diseño modular, por lo que puede
  interactuar y usarse, por ejemplo, para crear herramientas de análisis de código estático, lo que se vuelve cada vez más importante ()

De http://clang.debian.net/

• clang ahora está listo para construir software para producción (ya sea para C, C ++ u Objective-C). Este compilador proporciona muchas más advertencias y errores interesantes que el paquete gcc mientras no tiene el mismo legado que gcc.

La razón por la que lleva mucho tiempo es porque se necesita mucho trabajo para obtener una base sólida para construir los encabezados. La forma en que mingw-w64 parece funcionar es construir una biblioteca sólida similar a pthreads en Windows. Hay menos gruñidos aguas arriba sobre eso que introducir una dependencia en el subproceso nativo de la API de Windows.

mingw-w64 implementa <thread>y los otros encabezados C ++ 11 en la parte superior de su propia winpthreadsbiblioteca. Esto debería estar disponible para probar tanto en Mingw-builds como en las distribuciones de rubenvb de la cadena de herramientas mingw-w64. Recomendaría seguir las listas de correo mingw-w64 si desea realizar un seguimiento de dónde se realiza la mayor parte del trabajo en Windows GCC nativo.

El Proyecto Qt tiene una página wiki que detalla sus recomendaciones actuales y una vista general de las cadenas de herramientas de GCC en Windows, consulte esta página wiki del Proyecto Qt .