Czy GCC umiera bez obsługi wątków w systemie Windows? [Zamknięte]

Potrzebuję opinii. GCC zawsze był bardzo dobrym kompilatorem, ale ostatnio traci „atrakcyjność”. Właśnie odkryłem, że w Windows GCC nie ma std::threadwsparcia, zmuszając użytkowników Windows do korzystania z innego kompilatora, ponieważ najbardziej ekscytująca funkcja wciąż jest niedostępna.

Ale dlaczego tak naprawdę GCC nadal nie obsługuje wątków w systemie Windows? Problemy z licencją? Niezgodności ABI? (Cóż, istnieje już kilka bibliotek wieloplatformowych używających wielowątkowości: boost, POCO, SDL, wxwidgets itp. Czy nie byłoby łatwo używać już istniejącego i licencjonowanego kodu MIT / libpng, aby dopasować ten otwór zamiast wysyłania wydań GCC bez obsługi wątków?)

Ostatnio, patrząc na porównania kompilatorów, GCC ma najszersze wsparcie dla funkcji C ++ 11 w porównaniu z innymi kompilatorami, z wyjątkiem faktu, że w Windowsie nie jest to prawdą, ponieważ wciąż brakuje nam atomów, muteksów i wątków: /

Chciałbym dowiedzieć się więcej na ten temat, ale jedyne, co mogę znaleźć, to ludzie proszący o pomoc, ponieważ:

„wątek” nie istnieje w standardowej przestrzeni nazw

Patrząc na śledzenie biletów i dyskusje mailowe GCC / TDM-GCC, od 2009 r. Pojawiły się prośby o wsparcie wątków. Możliwe, że po 4 latach wciąż nie ma rozwiązania? Co się naprawdę dzieje

Zrozumiałem, że GCC spada z łaski, ponieważ utrzymujący go ludzie stali się nieco aroganccy, a teraz, gdy LLVM jest tutaj (i jest bardzo dobry), ludzie głosują nogami.

Slashdot rozmawiał o nowym wsparciu LLVM dla C ++ 11 . _merlin mówi:

Och, nie sądzę, żeby ktokolwiek myślał, że to zło, tylko że to raczej interes własny niż hojność. Fenomenalna popularność GCC spowodowała, że ​​jej opiekunowie zaczęli masować ego i zachowywać się jak totalni [ * *** ]. Błędy są wprowadzane szybciej niż Red Hat, a Apple może zaakceptować łaty i mają nieprzyjemny zwyczaj nie patrzeć na raporty o błędach, a następnie zamykać je z powodu braku aktywności bez faktycznego ich naprawiania

które wpisują się w twoją obserwację dotyczącą 4-letniego opóźnienia.

Popularność i użyteczność GCC nie jest wątpliwa.

• GCC jest nadal świetnym kompilatorem i najczęściej używanym.
• GCC obsługuje języki, do których nie dąży clang, takie jak Java, Ada, FORTRAN itp.
• GCC obsługuje więcej celów niż LLVM.
• GCC obsługuje C ++ 11

Od https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build na http://code.google.com/p/mingw-builds/downloads/list obsługuje wątki .

Ale ważnym czynnikiem jest Licencja.

• GCC jest licencjonowany na licencji GPL. clang korzysta z licencji BSD, która pozwala na osadzenie jej w oprogramowaniu, które nie jest objęte licencją GPL.
• Głównym powodem przejścia z GCC na Clang jest niezgodność licencji GCC v3 GCC z celami projektu FreeBSD.

FreeBSD ma niełatwe relacje z GPL. Zwolennicy licencji BSD uważają, że prawdziwie wolne oprogramowanie nie ma ograniczeń użytkowania. Zwolennicy GPL uważają, że ograniczenia są konieczne w celu ochrony wolności oprogramowania, a zwłaszcza, że ​​możliwość tworzenia niewolnego oprogramowania z wolnego oprogramowania jest niesprawiedliwą formą władzy, a nie wolności. W miarę możliwości projekt FreeBSD stara się unikać korzystania z GPL (szczegółowe informacje https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Inne ważne uwagi

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

• Clang AST i projekt mają być zrozumiałe dla każdego, kto zna języki, których dotyczy, i który ma podstawową wiedzę na temat działania kompilatora. GCC ma bardzo starą bazę kodu, która przedstawia stromą krzywą uczenia się nowym deweloperom.
• Clang został zaprojektowany jako interfejs API od samego początku, dzięki czemu może być ponownie wykorzystywany przez narzędzia analizy źródła, refaktoryzację, IDE (itp.), A także do generowania kodu. GCC jest zbudowany jako monolityczny kompilator statyczny, co sprawia, że ​​niezwykle trudno jest go używać jako API i integrować z innymi narzędziami. Co więcej, jego historyczny wygląd i obecna polityka utrudniają oddzielenie frontu od reszty kompilatora.
• Różne decyzje projektowe GCC bardzo utrudniają ponowne użycie: jego system kompilacji jest trudny do modyfikacji, nie można połączyć wielu celów w jeden plik binarny, nie można połączyć wielu interfejsów w jeden plik binarny, używa niestandardowego modułu wyrzucania elementów bezużytecznych, intensywnie wykorzystuje zmienne globalne, nie ma możliwości ponownego wysłania ani wielowątkowości itp. Clang nie ma żadnego z tych problemów.
• Dla każdego tokena clang śledzi informacje o tym, gdzie został napisany i gdzie ostatecznie został rozwinięty, jeśli był zaangażowany w makro. GCC nie śledzi informacji o instancjach makr podczas analizowania kodu źródłowego. To bardzo utrudnia narzędziom do przepisywania kodu źródłowego (np. Do refaktoryzacji) pracę w obecności (nawet prostych) makr.
• Clang nie domyślnie upraszcza kodu, ponieważ analizuje go tak jak GCC. Powoduje to wiele problemów dla narzędzi analizy źródła: jako prosty przykład, jeśli napiszesz „xx” w kodzie źródłowym, GCC AST będzie zawierać „0”, bez wzmianki o „x”. Jest to bardzo złe dla narzędzia refaktoryzującego, które chce zmienić nazwę „x”.
• Clang może serializować AST na dysk i wczytywać go z powrotem do innego programu, który jest przydatny do analizy całego programu. GCC tego nie ma. Mechanizm PCH GCC (który jest tylko zrzutem pamięci pamięci kompilatora) jest powiązany, ale pod względem architektonicznym jest w stanie tylko odczytać zrzut z powrotem do dokładnie tego samego pliku wykonywalnego, który go stworzył (nie jest to format strukturalny).
• Clang jest znacznie szybszy i zużywa znacznie mniej pamięci niż GCC.
• Clang dąży do zapewnienia wyjątkowo jasnej i zwięzłej diagnostyki (komunikaty o błędach i ostrzeżeniach) oraz obejmuje obsługę ekspresyjnej diagnostyki. Ostrzeżenia GCC są czasami akceptowalne, ale często mylące i nie obsługują ekspresyjnej diagnostyki. Clang konsekwentnie zachowuje także typedefy w diagnostyce, pokazując rozszerzenia makr i wiele innych funkcji.
• Clang dziedziczy wiele funkcji po wykorzystaniu LLVM jako zaplecza, w tym obsługę reprezentacji kodu bajtowego dla kodu pośredniego, optymalizatory wtykowe, wsparcie optymalizacji czasu łącza, kompilacja Just-In-Time, możliwość łączenia wielu generatorów kodu itp. .
• Wsparcie Clanga dla C ++ jest pod wieloma względami bardziej zgodne niż GCC (np. Zgodne wyszukiwanie nazw dwufazowych).

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

• Zaletą llvm / clang jest jego modułowa konstrukcja, dzięki czemu można go
  interfejsować i wykorzystywać na przykład do tworzenia statycznych narzędzi do analizy kodu, co staje się coraz ważniejsze ()

Od http://clang.debian.net/

• clang jest teraz gotowy do budowy oprogramowania do produkcji (dla C, C ++ lub Objective-C). Ten kompilator zapewnia o wiele więcej ostrzeżeń i interesujących błędów niż pakiet gcc, ale nie ma tego samego dziedzictwa co gcc.

Powodem, dla którego zajmuje to dużo czasu, jest to, że uzyskanie solidnego fundamentu do zbudowania nagłówków wymaga dużo pracy. Sposób, w jaki mingw-w64 wydaje się być bo, polega na zbudowaniu solidnej biblioteki podobnej do pthreads w systemie Windows. Jest mniej zrzędliwego upstream niż wprowadzenie zależności od natywnego wątkowania Windows API.

Implementuje mingw-w64 <thread>i inne nagłówki C ++ 11 nad własną winpthreadsbiblioteką. Powinno to być dostępne do testowania zarówno w kompilacjach Mingw, jak i dystrybucjach rubenvb zestawu narzędzi mingw-w64. Polecam śledzenie list mailingowych mingw-w64, jeśli chcesz śledzić, gdzie wykonuje się większość pracy nad natywną pracą Windows GCC.

Projekt Qt ma stronę wiki opisującą ich aktualne rekomendacje oraz przegląd łańcuchów narzędzi GCC w systemie Windows, patrz strona wiki projektu Qt .