GCC est-il en train de mourir sans la prise en charge des threads sous Windows? [fermé]

31

J'ai besoin d'un avis. GCC a toujours été un très bon compilateur, mais récemment il perd son "attrait". Je viens de découvrir que sous Windows, GCC ne prend pas en std::threadcharge, ce qui oblige les utilisateurs de Windows à utiliser un autre compilateur car la fonctionnalité la plus intéressante est toujours manquante.

Mais pourquoi GCC n'a-t-il pas encore de support des threads sous Windows? Problèmes de licence? Incompatibilités ABI? (Eh bien, il existe déjà plusieurs bibliothèques multiplateformes utilisant le multithreading: boost, POCO, SDL, wxwidgets, etc. Ne serait-il pas simple d'utiliser déjà existant, et sous licence MIT / libpng, du code pour s'adapter à ce trou au lieu d'expédier des versions GCC sans support de thread?)

Récemment, en regardant les comparaisons de compilateurs, GCC a la prise en charge la plus large des fonctionnalités C ++ 11 par rapport aux autres compilateurs, à l'exception du fait que sous Windows, ce n'est pas vrai car nous manquons toujours d'atomiques, de mutex et de threads: /

J'aimerais en savoir plus sur ce sujet, mais la seule chose que je puisse trouver, ce sont les gens qui demandent de l'aide parce que:

"thread" n'existe pas dans l'espace de noms std

En regardant le suivi des tickets et les discussions par mail de GCC / TDM-GCC, il y a eu des demandes de support de thread depuis 2009. Possible qu'après 4 ans toujours pas de solution? Que se passe-t-il vraiment?

Développeur de jeu
la source
8
gcc est toujours bon, peu importe ce que vous avez découvert récemment.
ott--
1
J'ai juste aimé std :: thread. ce n'était pas si difficile à mettre en œuvre. Prenez simplement des modèles variadics et par exemple un thread SDL et vous pouvez créer une classe équivalente à std :: thread: /
GameDeveloper
12
Je dirais presque étant donné l'incapacité des programmeurs moyens à écrire des applications multi-threads fiables, aucun support de thread n'est un bonus .....
mattnz
3
vous vous plaignez des bibliothèques, pas spécifiquement du compilateur.
wirrbel
2
GCC est populaire, c'est vrai. Mais je ne dirais pas que ça a toujours été "un très bon compilateur". Il y a des années, les gens expérimentaient ICC sous Linux, à cause des binaires lents et gonflés produits par GCC. OTOH, tous les grands projets open source utilisent VS pour compiler la version Windows de leur code, encore une fois, car GCC produit un ballonnement lent en comparaison.
vartec

Réponses:

23

J'ai compris que GCC est en train de tomber en disgrâce parce que les gens qui le maintiennent sont devenus quelque peu arrogants, et maintenant que LLVM est ici (et c'est très bien), les gens votent avec les pieds.

Slashdot a discuté du nouveau support de LLVM pour C ++ 11 . _merlin dit:

Oh, je ne pense pas que quiconque pense que c'est mal, juste que c'est de l'intérêt personnel plutôt que de la générosité. La popularité phénoménale de GCC a conduit ses responsables à développer des ego massifs et à se comporter comme un total [ * *** ]. Les bogues sont introduits plus rapidement que Red Hat et Apple peut faire accepter les correctifs, et ils ont la mauvaise habitude de ne pas consulter les rapports de bogues, puis de les fermer en raison de l'inactivité sans les corriger

ce qui correspond à votre observation sur le retard de 4 ans.

gbjbaanb
la source
Vous pouvez également trouver developers.slashdot.org/… (également par _merlin) pour signaler d'autres problèmes de compilation pour non-linux avec gcc.
3
Ce n'est pas seulement LLVM, les éditions Visual Studio Express sont une autre alternative viable et gratuite (étant donné que la question concerne spécifiquement std::threadWindows qui est pris en charge dans VS2012 EE)
MSalters
1
trop mauvais VS2012 n'a pas un support complet pour std :: thread (par exemple pas de thread_localvariables)
alrikai
Cela a-t-il changé du tout de nos jours?
Hashim
29

La popularité et la convivialité de GCC ne sont pas discutables.

À partir de https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build sur http://code.google.com/p/mingw-builds/downloads/list prend en charge les threads .

Mais la considération importante est la licence.

FreeBSD a une relation difficile avec la GPL. Les partisans de la licence BSD croient que les logiciels vraiment gratuits n'ont aucune restriction d'utilisation. Les partisans de la GPL estiment que des restrictions sont nécessaires pour protéger la liberté des logiciels, et en particulier que la capacité de créer des logiciels non libres à partir de logiciels libres est une forme de pouvoir injuste plutôt qu'une liberté. Le projet FreeBSD, dans la mesure du possible, essaie d'éviter l'utilisation de la GPL (Pour plus de détails https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Autres considérations importantes

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

  • Les Clang AST et leur conception sont destinés à être facilement compréhensibles par toute personne familiarisée avec les langages impliqués et ayant une compréhension de base du fonctionnement d'un compilateur. GCC a une très ancienne base de code qui présente une courbe d'apprentissage abrupte aux nouveaux développeurs.
  • Clang est conçu comme une API depuis sa création, ce qui lui permet d'être réutilisé par les outils d'analyse de source, le refactoring, les IDE (etc.) ainsi que pour la génération de code. GCC est conçu comme un compilateur statique monolithique, ce qui le rend extrêmement difficile à utiliser comme API et à intégrer dans d'autres outils. En outre, sa conception historique et sa politique actuelle rendent difficile la dissociation du frontal du reste du compilateur.
  • Diverses décisions de conception GCC rendent sa réutilisation très difficile: son système de construction est difficile à modifier, vous ne pouvez pas lier plusieurs cibles en un seul binaire, vous ne pouvez pas lier plusieurs frontaux en un seul binaire, il utilise un garbage collector personnalisé, utilise largement les variables globales, n'est pas réentrant ou multi-threadable, etc. Clang n'a aucun de ces problèmes.
  • Pour chaque jeton, clang suit les informations sur l'endroit où il a été écrit et où il a finalement été développé s'il était impliqué dans une macro. GCC ne suit pas les informations sur les instanciations de macro lors de l'analyse du code source. Il est donc très difficile pour les outils de réécriture source (par exemple pour la refactorisation) de fonctionner en présence de macros (même simples).
  • Clang ne simplifie pas implicitement le code car il le traite comme le fait GCC. Cela pose de nombreux problèmes pour les outils d'analyse de source: comme exemple simple, si vous écrivez "xx" dans votre code source, l'AST GCC contiendra "0", sans mention de 'x'. C'est extrêmement mauvais pour un outil de refactoring qui veut renommer 'x'.
  • Clang peut sérialiser son AST sur disque et le relire dans un autre programme, ce qui est utile pour l'analyse de programme entier. GCC ne l'a pas. Le mécanisme PCH de GCC (qui est juste un vidage de l'image de la mémoire du compilateur) est lié, mais est architecturalement uniquement capable de lire le vidage dans le même exécutable que celui qui l'a produit (ce n'est pas un format structuré).
  • Clang est beaucoup plus rapide et utilise beaucoup moins de mémoire que GCC.
  • Clang vise à fournir des diagnostics extrêmement clairs et concis (messages d'erreur et d'avertissement), et inclut la prise en charge des diagnostics expressifs. Les avertissements de GCC sont parfois acceptables, mais sont souvent déroutants et ne prennent pas en charge les diagnostics expressifs. Clang conserve également les typedefs dans les diagnostics de manière cohérente, montrant les extensions de macro et de nombreuses autres fonctionnalités.
  • Clang hérite d'un certain nombre de fonctionnalités de son utilisation de LLVM en tant que backend, y compris la prise en charge d'une représentation de bytecode pour le code intermédiaire, les optimiseurs enfichables, la prise en charge de l'optimisation de la liaison, la compilation Just-In-Time, la possibilité de lier plusieurs générateurs de code, etc. .
  • Le support de Clang pour C ++ est plus conforme que GCC à bien des égards (par exemple, recherche de nom conforme en deux phases).

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

  • L'avantage de llvm / clang est sa conception modulaire, il peut donc être
    interfacé et utilisé par exemple pour créer des outils d'analyse de code statique, ce qui devient de plus en plus important ()

Depuis http://clang.debian.net/

  • clang est maintenant prêt à créer des logiciels de production (pour C, C ++ ou Objective-C). Ce compilateur fournit beaucoup plus d'avertissements et d'erreurs intéressantes que la suite gcc sans porter le même héritage que gcc.
Md Mahbubur Rahman
la source
2
La meilleure réponse de tous les temps!
Vorac
3
Juste pour être à jour: GCC suit l'expansion des macros depuis la 4.8, avec l'option -ftrack-macro-expansion, désormais activée par défaut :)
Morwenn
Un autre problème avec la tentative de simplification de l'arborescence source au moment de l'analyse est qu'il existe de nombreuses situations où un peu de syntaxe ne doit générer aucun code mais doit affecter les optimisations autorisées. Si fooet moosont des pointeurs vers différents types de structure, qui ont tous deux un champ bardans leur séquence initiale, l'écriture *&foo->baret la lecture *&moo->bardevraient faire en sorte que la lecture voit l'écriture, car le seul type efficace utilisé dans l'un ou l'autre accès est le type de bar. GCC, cependant, semble filtrer le *&et percole donc les types de fooet moo...
supercat
... via l'adresse de l'opérateur, qui n'est justifiée par rien de ce que je peux trouver dans la norme.
supercat
11

La raison pour laquelle cela prend beaucoup de temps est qu'il faut beaucoup de travail pour obtenir une base solide pour construire les en-têtes. La façon dont mingw-w64 semble bo est de construire une bibliothèque solide de type pthreads sous Windows. Il y a moins de grincheux en amont à ce sujet que d'introduire une dépendance sur le thread natif de l'API Windows.

mingw-w64 implémente <thread>et les autres en-têtes C ++ 11 au-dessus de leur propre winpthreadsbibliothèque. Cela devrait être disponible pour les tests dans les builds Mingw et les distributions rubenvb de la chaîne d'outils mingw-w64. Je recommanderais de suivre les listes de diffusion mingw-w64 si vous souhaitez suivre où la plupart du travail sur le travail natif de Windows GCC est effectué.

Le projet Qt a une page wiki détaillant leur recommandation actuelle et une vue d'ensemble des chaînes d'outils GCC sur Windows, voir cette page wiki du projet Qt .

Lars Viklund
la source