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

31

Мне нужно мнение. 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 года все еще нет решения? Что на самом деле происходит?

Разработчик игр
источник
8
GCC все еще хорош, независимо от того, что вы недавно узнали.
ot--
1
Мне просто понравился std :: thread. это было не так сложно реализовать. Просто возьмите шаблоны variadics и, например, поток SDL, и вы можете создать класс, эквивалентный std :: thread: /
GameDeveloper
12
Я почти спорил бы, учитывая, что среднестатистические программисты не могут писать надежные многопоточные приложения, поддержка потоков не является бонусом .....
mattnz
3
Вы жалуетесь на библиотеки, а не на компилятор.
wirrbel
2
GCC популярен, это правда. Но я бы не сказал, что это был «всегда очень хороший компилятор». Много лет назад люди экспериментировали с ICC в Linux из-за медленных и раздутых двоичных файлов, которые создавал GCC. OTOH, все основные проекты с открытым исходным кодом используют VS, чтобы скомпилировать версию своего кода для Windows, опять же, потому что GCC производит медленное раздувание по сравнению.
vartec

Ответы:

23

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

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

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

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

gbjbaanb
источник
Вы также можете найти developers.slashdot.org/… (также _merlin), чтобы указать на другие проблемы с компиляцией не для Linux с gcc.
3
Это не просто LLVM, выпуски Visual Studio Express Edition - еще одна жизнеспособная, бесплатная альтернатива (учитывая, что речь идет конкретно о std::threadWindows, которая поддерживается в VS2012 EE)
MSalters
1
Жаль, что VS2012 не имеет полной поддержки std :: thread (например, без thread_localпеременных)
alrikai
Изменилось ли это вообще в наши дни?
Хашим
29

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

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

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

У 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.
Md Mahbubur Rahman
источник
2
Лучший ответ!
Vorac
3
Просто чтобы быть в курсе: GCC отслеживает расширение макросов начиная с 4.8, с возможностью -ftrack-macro-expansion, теперь включенной по умолчанию :)
Morwenn
Другая проблема, связанная с попыткой упростить дерево исходных текстов во время синтаксического анализа, состоит в том, что существует много ситуаций, когда немного синтаксиса не должно генерировать какой-либо код, но должно влиять на то, какие оптимизации разрешены. Если fooи mooявляются указателями на разные типы структур, у обоих из которых есть поля barкак часть их начальной последовательности, запись *&foo->barи чтение *&moo->barдолжны приводить к чтению, видящему запись, так как единственный эффективный тип, используемый в любом доступе, это тип bar. GCC, однако, похоже, отфильтровывает *&и, таким образом, просачивает типы fooи moo...
суперкат
... через адрес оператора, что ничем не оправдано в Стандарте.
суперкат
11

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

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

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

Ларс Виклунд
источник