Чи 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 . _merlin каже:

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

що звучить у вашому спостереженні про 4-річну затримку.

Популярність та зручність використання GCC не викликають сумнівів.

• GCC все ще чудовий компілятор і найбільш широко використовується.
• GCC підтримує мови, на які кланг не націлений, такі як 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 v3 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/comppare.html#gcc

• Clans ASTs та дизайн повинні бути легко зрозумілими всім, хто знайомий з мовами, що займаються, та хто має базове розуміння того, як працює компілятор. GCC має дуже стару базу коду, яка представляє круту криву навчання для нових розробників.
• Кланг розроблений як API з самого його створення, що дозволяє використовувати його повторно за допомогою інструментів аналізу джерел, рефакторингу, IDE (тощо), а також для генерації коду. GCC побудований як монолітний статичний компілятор, що робить його надзвичайно важким для використання як API та інтеграції в інші інструменти. Крім того, його історичний дизайн та поточна політика ускладнюють відокремлення передової частини решти компілятора.
• Різні дизайнерські рішення GCC ускладнюють повторне використання: його систему складання важко модифікувати, ви не можете зв'язати кілька цілей в один двійковий файл, ви не можете зв'язати декілька передніх частин в один двійковий файл, він використовує спеціальний збирач сміття, широко використовує глобальні змінні, не є ретрансляційними або багатозавантажуваними тощо. У Clang немає жодної з цих проблем.
• Для кожного маркера clang відслідковує інформацію про те, де він був написаний і де він був врешті-решт розширений, якщо він був задіяний у макросі. GCC не відслідковує інформацію про макроісторії під час аналізу вихідного коду. Це дуже заважає інструментам для переписування джерел (наприклад, для рефакторингу) працювати за наявності (навіть простих) макросів.
• Clang не чітко спрощує код, оскільки він аналізує його, як це робить GCC. Це спричиняє багато проблем із інструментами аналізу джерела: як один простий приклад, якщо ви пишете "xx" у своєму вихідному коді, GCC AST буде містити "0", без згадки "x". Це вкрай погано для інструменту рефакторингу, який хоче перейменувати "x".
• Clang може серіалізувати свій AST на диск і прочитати його назад в іншій програмі, що корисно для аналізу цілої програми. У GCC цього немає. Механізм PCH GCC (який є лише дампами зображення пам'яті компілятора) пов'язаний, але архітектурно він може лише зчитувати дамп в точно такий же виконуваний файл, як і той, що його створив (це не структурований формат).
• Clang набагато швидше і використовує набагато менше пам'яті, ніж GCC.
• Кланг має на меті забезпечити надзвичайно чітку та стисну діагностику (повідомлення про помилки та попередження) та включає підтримку експресивної діагностики. Попередження GCC іноді є прийнятними, але часто заплутані і не підтримують експресивної діагностики. Кланг також зберігає typedefs у діагностиці послідовно, демонструючи розширення макросу та багато інших функцій.
• Кланг успадковує ряд функцій від використання LLVM як резервного, включаючи підтримку представлення байт-коду для проміжного коду, підключаються оптимізатори, підтримку оптимізації посилання, час компіляції, можливість з'єднання в декількох генераторах коду тощо .
• Підтримка Кланг для 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 - це створити міцну бібліотеку, схожу на pthreads, для Windows. Існує менше бурхливості вгору за течією, ніж введення залежності від нативної нитки API API.

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

У проекті Qt є вікі-сторінка з детальною інформацією про їхні поточні рекомендації та надмірний вигляд ланцюжків інструментів GCC на windows, див. Цю вікі-сторінку проекту Qt Project .