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

31 голос | спросил GameDeveloper 22 AMpMon, 22 Apr 2013 00:37:30 +040037Monday 2013, 00:37:30

3 ответа


23

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

Slashdot обсуждал Новая поддержка LLVM для C ++ 11 . _merlin говорит:

  

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

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

ответил gbjbaanb 22 AMpMon, 22 Apr 2013 03:06:15 +040006Monday 2013, 03:06:15
29

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

  

С    https://stackoverflow.com/questions/12210102/does-gcc-4- 7-1-поддержка-тема   mingw на http://code.google.com/p/mingw-builds /загрузки /список   поддерживает потоки.

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

  

У FreeBSD есть непростые отношения с GPL. Защитники BSD-лицензии   считают, что действительно бесплатное программное обеспечение не имеет ограничений по использованию. GPL   адвокаты считают, что ограничения необходимы для защиты   свободы программного обеспечения и, в частности, что способность создавать несвободные   программное обеспечение из бесплатного программного обеспечения является несправедливой формой власти, а не   свобода. Проект FreeBSD, где это возможно, пытается избежать использования   от GPL (Подробнее    https://unix.stackexchange.com/вопросы /49906 /почему-это-freebsd-протестующий-GCC-в-пользу-оф-лязгом-LLVM )

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

Из http://clang.llvm.org/comparison.html#gcc

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

С     http://www.linuxquestions.org/questions/slackware -14 /НКУ-против-LLVM-931034 /

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

От http://clang.debian.net/

  • clang теперь готов к созданию программного обеспечения для производства (либо для C, C ++ или Objective-C). Этот компилятор предоставляет гораздо больше предупреждений и интересные ошибки, чем пакет gcc, не legacy как gcc.
ответил Md Mahbubur Rahman 22 PMpMon, 22 Apr 2013 19:13:11 +040013Monday 2013, 19:13:11
11

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

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

В проекте Qt есть страница вики, в которой подробно изложены их текущая рекомендация и вид сверху на GCC toolchains на окнах, см. эту вики-страницу проекта Qt .

ответил Lars Viklund 22 PMpMon, 22 Apr 2013 18:40:43 +040040Monday 2013, 18:40:43

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132