GCC умирает без поддержки потоков в Windows? [закрыто]

Мне нужно мнение. GCC всегда был очень хорошим компилятором, но в последнее время он теряет «привлекательность». Я только что обнаружил, что в Windows GCC нет std::threadподдержки, заставляющей пользователей Windows использовать другой компилятор, потому что самая захватывающая функция все еще отсутствует.

Но почему на самом деле GCC до сих пор не поддерживает потоки под Windows? Проблемы с лицензией? ABI несовместимости? (Хорошо, что уже есть несколько кроссплатформенных библиотек, использующих многопоточность: boost, POCO, SDL, wxwidgets и т. Д. Разве не было бы просто использовать уже существующий и лицензированный MIT / libpng код, подходящий для этой дыры, вместо доставки релизов GCC без поддержки потоков?)

Недавно, глядя на сравнения компиляторов, GCC имеет самую широкую поддержку функций C ++ 11 по сравнению с другими компиляторами, за исключением того факта, что в Windows это не так, потому что нам все еще не хватает атомарности, мьютексов и потоков:

Я хотел бы узнать больше об этой теме, но единственное, что я могу найти, это люди, которые обращаются за помощью, потому что:

"поток" не существует в пространстве имен std

Глядя на отслеживание заявок и обсуждения по почте GCC / TDM-GCC, с 2009 года были запросы на поддержку потоков. Возможно, что через 4 года все еще нет решения? Что на самом деле происходит?

Я понял, что GCC теряет благосклонность, потому что люди, поддерживающие его, стали несколько высокомерными, и теперь, когда LLVM здесь (и это очень хорошо), люди голосуют ногами.

Slashdot обсудил новую поддержку LLVM для C ++ 11 . _мерлин говорит:

О, я не думаю, что кто-то думает, что это зло, просто это личная заинтересованность, а не щедрость. Феноменальная популярность GCC привела к тому, что его сопровождающие накапливают огромное эго и ведут себя как все [ * *** ]. Ошибки появляются быстрее, чем в Red Hat, и Apple может принимать исправления для них, и у них есть неприятная привычка - не просматривать отчеты об ошибках, а затем закрывать их из-за неактивности, фактически не исправляя их.

что связано с вашим наблюдением о 4-летней задержке.

Популярность и удобство использования GCC не вызывает сомнений.

• GCC по-прежнему отличный компилятор и наиболее широко используемый.
• GCC поддерживает языки, на которые не ориентирован clang, такие как Java, Ada, FORTRAN и т. Д.
• GCC поддерживает больше целей, чем LLVM.
• GCC поддерживает C ++ 11

Из https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build по адресу http://code.google.com/p/mingw-builds/downloads/list поддерживает потоки ,

Но важным фактором является лицензия.

• GCC лицензируется по лицензии GPL. clang использует лицензию BSD, которая позволяет встраивать его в программное обеспечение, не лицензированное по лицензии GPL.
• Основной причиной перехода с GCC на Clang является несовместимость лицензии GCC GPL v3 с целями проекта FreeBSD.

У FreeBSD непростые отношения с GPL. Сторонники BSD-лицензии считают, что по-настоящему свободное программное обеспечение не имеет ограничений по использованию. Сторонники GPL считают, что ограничения необходимы для защиты свободы программного обеспечения, и, в частности, что возможность создавать несвободное программное обеспечение из свободного программного обеспечения является несправедливой формой власти, а не свободой. Проект FreeBSD, где это возможно, старается избегать использования GPL (для подробностей https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Другие важные соображения

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

• AST и дизайн Clang предназначены для того, чтобы их было легко понять любому, кто знаком с задействованными языками и имеет общее представление о том, как работает компилятор. GCC имеет очень старую кодовую базу, которая представляет собой крутой курс обучения для новых разработчиков.
• Clang спроектирован как API с самого начала, что позволяет использовать его инструментами анализа исходного кода, рефакторинга, IDE (и т. Д.), А также для генерации кода. GCC построен как монолитный статический компилятор, что делает его чрезвычайно трудным для использования в качестве API и интеграции с другими инструментами. Кроме того, его исторический дизайн и текущая политика затрудняют отделение внешнего интерфейса от остальной части компилятора.
• Различные конструктивные решения GCC затрудняют повторное использование: его систему сборки сложно изменить, вы не можете связать несколько целей в один двоичный файл, вы не можете связать несколько внешних интерфейсов в один двоичный файл, он использует собственный сборщик мусора, широко использует глобальные переменные, не является повторно входящим или многопоточным и т. д. Clang не имеет ни одной из этих проблем.
• Для каждого токена clang отслеживает информацию о том, где он был написан и где он был в конечном итоге расширен, если он был задействован в макросе. GCC не отслеживает информацию об экземплярах макросов при разборе исходного кода. Это очень затрудняет работу инструментов переписывания исходного кода (например, для рефакторинга) в присутствии (даже простых) макросов.
• Clang не упрощает код неявным образом, так как анализирует его, как GCC. Это вызывает много проблем для инструментов анализа исходного кода: в качестве одного простого примера, если вы напишите «xx» в своем исходном коде, GCC AST будет содержать «0», без упоминания «x». Это очень плохо для инструмента рефакторинга, который хочет переименовать «х».
• Clang может сериализовать свой AST на диск и прочитать его обратно в другую программу, что полезно для анализа всей программы. GCC не имеет этого. Механизм GCC PCH (который является просто дампом образа памяти компилятора) связан, но архитектурно способен считывать дамп обратно в тот же исполняемый файл, что и тот, который его создал (это не структурированный формат).
• Clang намного быстрее и использует гораздо меньше памяти, чем GCC.
• Целью Clang является предоставление чрезвычайно четкой и краткой диагностики (сообщений об ошибках и предупреждений), а также поддержка экспрессивной диагностики. Предупреждения GCC иногда приемлемы, но часто сбивают с толку и не поддерживают экспресс-диагностику. Clang также постоянно сохраняет typedef в диагностике, показывая расширения макросов и многие другие функции.
• Clang унаследовал ряд функций от использования LLVM в качестве бэкэнда, включая поддержку представления байт-кода для промежуточного кода, подключаемых оптимизаторов, поддержку оптимизации во время соединения, компиляцию Just-In-Time, возможность ссылаться в нескольких генераторах кода и т. Д. ,
• Поддержка Clang для C ++ более совместима, чем GCC, во многих отношениях (например, совместим двухфазный поиск имен).

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

• Преимущество llvm / clang заключается в его модульной конструкции, поэтому его можно
  связывать и использовать, например, для создания инструментов статического анализа кода, что становится все более и более важным ()

С http://clang.debian.net/

• Теперь clang готов создавать программное обеспечение для производства (для C, C ++ или Objective-C). Этот компилятор выдает гораздо больше предупреждений и интересных ошибок, чем набор gcc, но не несет того же наследия, что и gcc.

Причина, по которой это занимает много времени, состоит в том, что требуется много работы, чтобы получить прочную основу для построения заголовков на вершине. Казалось бы, mingw-w64 - это создать в Windows основанную на pthreads библиотеку. В этом есть меньшая раздражительность, чем введение зависимости от собственной многопоточности Windows API.

Mingw-w64 реализует <thread>и другие заголовки C ++ 11 поверх их собственной winpthreadsбиблиотеки. Это должно быть доступно для тестирования как в дистрибутивах Mingw-build, так и в Rubenvb набора инструментов mingw-w64. Я бы порекомендовал следовать спискам рассылки mingw-w64, если вы хотите отслеживать, где выполняется большая часть работы над родной Windows GCC.

Проект Qt имеет вики-страницу с подробным описанием их текущих рекомендаций и обзором цепочек инструментов GCC на окнах, смотрите эту вики-страницу проекта Qt .