Apakah GCC sekarat tanpa dukungan thread pada Windows? [Tutup]


31

Saya butuh pendapat. GCC selalu kompiler yang sangat baik, tetapi baru-baru ini kehilangan "banding". Saya baru saja menemukan bahwa pada Windows GCC tidak memiliki std::threaddukungan, memaksa pengguna Windows untuk menggunakan kompiler lain karena fitur yang paling menarik masih hilang.

Tetapi mengapa GCC masih tidak memiliki dukungan utas di Windows? Masalah lisensi? Ketidakcocokan ABI? (Ya, sudah ada beberapa pustaka lintas platform menggunakan multithreading: boost, POCO, SDL, wxwidgets, dll. Tidakkah mudah untuk menggunakan yang sudah ada, dan MIT / libpng berlisensi, kode yang sesuai dengan lubang ini alih-alih mengirimkan rilis GCC tanpa dukungan utas?)

Baru-baru ini, melihat perbandingan kompiler, GCC memiliki dukungan terluas untuk fitur C ++ 11 sehubungan dengan kompiler lain, kecuali untuk fakta bahwa pada Windows ini tidak benar karena kami masih kekurangan atom, mutex, dan utas: /

Saya ingin tahu lebih banyak tentang topik ini, tetapi satu-satunya hal yang dapat saya temukan adalah orang-orang yang meminta bantuan karena:

"utas" tidak ada di namespace std

Melihat pelacakan tiket dan diskusi diskusi GCC / TDM-GCC, ada permintaan untuk dukungan utas sejak 2009. Mungkinkah setelah 4 tahun masih tidak ada solusi? Apa yang sebenarnya terjadi?


8
gcc masih bagus, tidak peduli apa yang baru Anda temukan.
ott--

1
Saya hanya suka std :: utas. itu bukan fitur yang sulit untuk diimplementasikan. Ambil saja templat variadics dan misalnya utas SDL dan Anda dapat membuat kelas yang setara dengan std :: utas: /
GameDeveloper

12
Saya hampir akan berdebat mengingat ketidakmampuan programmer rata-rata untuk menulis aplikasi multi-threaded yang andal, tidak ada dukungan thread adalah bonus .....
mattnz

3
Anda mengeluh tentang perpustakaan tidak secara khusus kompiler.
wirrbel

2
GCC populer, itu benar. Tapi saya tidak akan mengatakan, bahwa itu "selalu kompiler yang sangat bagus". Beberapa waktu yang lalu orang bereksperimen dengan ICC di Linux, karena biner yang lambat dan membengkak yang dihasilkan GCC. OTOH, semua proyek open source utama menggunakan VS untuk mengkompilasi versi Windows dari kode mereka, sekali lagi, karena GCC menghasilkan gembung lambat sebagai perbandingan.
vartec

Jawaban:


23

Saya mengerti bahwa GCC tidak disukai karena orang-orang yang mempertahankannya menjadi agak sombong, dan sekarang LLVM ada di sini (dan sangat baik) orang-orang memilih dengan kaki.

Slashdot berdiskusi tentang dukungan baru LLVM untuk C ++ 11 . _merlin mengatakan:

Oh saya tidak berpikir ada orang yang berpikir itu jahat, hanya saja itu kepentingan pribadi daripada kemurahan hati. Popularitas fenomenal GCC telah menyebabkan para pengelolanya menumbuhkan ego besar dan berperilaku seperti [ * *** ] total . Bug diperkenalkan lebih cepat daripada Red Hat dan Apple bisa mendapatkan tambalan untuk mereka diterima, dan mereka memiliki kebiasaan buruk untuk tidak melihat laporan bug, kemudian menutupnya karena tidak aktif tanpa benar-benar memperbaikinya

yang berbunyi dengan pengamatan Anda tentang penundaan 4 tahun.


Anda mungkin juga menemukan developers.slashdot.org/… (juga oleh _merlin) untuk menunjukkan masalah lain dengan kompilasi untuk non-linux dengan gcc.

3
Ini bukan hanya LLVM, Visual Studio Express Editions adalah alternatif lain yang layak dan gratis (mengingat pertanyaannya secara khusus tentang std::threadWindows yang didukung dalam VS2012 EE)
MSalters

1
VS2012 terlalu buruk tidak memiliki dukungan penuh untuk std :: thread (mis. tidak ada thread_localvariabel)
alrikai

Apakah ini berubah sama sekali di zaman modern?
Hashim

29

Popularitas dan kegunaan GCC tidak dipertanyakan.

Dari https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build di http://code.google.com/p/mingw-builds/downloads/list mendukung utas .

Namun pertimbangan penting adalah Lisensi.

FreeBSD memiliki hubungan yang tidak mudah dengan GPL. Pendukung lisensi BSD percaya bahwa perangkat lunak yang benar-benar gratis tidak memiliki batasan penggunaan. Pendukung GPL percaya bahwa pembatasan diperlukan untuk melindungi kebebasan perangkat lunak, dan khususnya bahwa kemampuan untuk membuat perangkat lunak tidak bebas dari perangkat lunak bebas adalah bentuk kekuatan yang tidak adil daripada kebebasan. Proyek FreeBSD, jika memungkinkan, mencoba menghindari penggunaan GPL (Untuk perincian https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

Pertimbangan penting lainnya

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

  • AST Dentang dan desain dimaksudkan agar mudah dimengerti oleh siapa saja yang akrab dengan bahasa yang terlibat dan yang memiliki pemahaman dasar tentang cara kerja kompiler. GCC memiliki basis kode yang sangat lama yang menyajikan kurva belajar yang curam untuk pengembang baru.
  • Dentang dirancang sebagai API dari awal, memungkinkan untuk digunakan kembali oleh alat analisis sumber, refactoring, IDE (dll) serta untuk pembuatan kode. GCC dibangun sebagai kompiler statis monolitik, yang membuatnya sangat sulit untuk digunakan sebagai API dan diintegrasikan ke dalam alat lain. Lebih jauh, desain historis dan kebijakan saat ini membuatnya sulit untuk memisahkan ujung depan dari bagian kompiler lainnya.
  • Berbagai keputusan desain GCC membuatnya sangat sulit untuk digunakan kembali: sistem build-nya sulit dimodifikasi, Anda tidak dapat menautkan banyak target menjadi satu biner, Anda tidak dapat menautkan beberapa ujung depan menjadi satu biner, ia menggunakan pengumpul sampah khusus, menggunakan variabel global secara luas, tidak reentrant atau multi-threadable, dll. Dentang tidak memiliki masalah ini.
  • Untuk setiap token, dentang melacak informasi tentang di mana ia ditulis dan di mana ia akhirnya diperluas jika terlibat dalam makro. GCC tidak melacak informasi tentang instantiations makro saat mem-parsing kode sumber. Ini membuatnya sangat sulit untuk alat penulisan ulang sumber (misalnya untuk refactoring) untuk bekerja di hadapan makro (bahkan sederhana).
  • Dentang tidak secara implisit menyederhanakan kode karena mem-parsingnya seperti yang dilakukan GCC. Melakukan hal itu menyebabkan banyak masalah untuk alat analisis sumber: sebagai salah satu contoh sederhana, jika Anda menulis "xx" dalam kode sumber Anda, GCC AST akan berisi "0", tanpa menyebutkan 'x'. Ini sangat buruk untuk alat refactoring yang ingin mengganti nama 'x'.
  • Dentang dapat membuat serial AST-nya ke disk dan membacanya kembali ke program lain, yang berguna untuk analisis seluruh program. GCC tidak memiliki ini. Mekanisme PCH GCC (yang hanya merupakan dump dari gambar memori kompiler) terkait, tetapi secara arsitektur hanya dapat membaca dump kembali ke executable yang sama persis seperti yang menghasilkannya (itu bukan format terstruktur).
  • Dentang jauh lebih cepat dan menggunakan memori jauh lebih sedikit daripada GCC.
  • Dentang bertujuan untuk memberikan diagnostik yang sangat jelas dan ringkas (pesan kesalahan dan peringatan), dan termasuk dukungan untuk diagnostik ekspresif. Peringatan GCC terkadang dapat diterima, tetapi seringkali membingungkan dan tidak mendukung diagnostik ekspresif. Dentang juga mempertahankan typedef dalam diagnostik secara konsisten, menunjukkan ekspansi makro dan banyak fitur lainnya.
  • Dentang mewarisi sejumlah fitur dari penggunaan LLVM sebagai backend, termasuk dukungan untuk representasi bytecode untuk kode perantara, pengoptimal pluggable, dukungan optimisasi tautan-waktu, kompilasi Just-In-Time, kemampuan untuk menghubungkan berbagai generator kode, dll. .
  • Dukungan dentang untuk C ++ lebih sesuai daripada GCC dalam banyak hal (misalnya pencarian nama dua fase yang sesuai).

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

  • Keuntungan llvm / clang adalah desain modularnya, sehingga dapat
    dihubungkan dan digunakan misalnya untuk membuat alat analisis kode statis, yang menjadi semakin penting ()

Dari http://clang.debian.net/

  • dentang sekarang siap untuk membangun perangkat lunak untuk produksi (baik untuk C, C ++ atau Objective-C). Kompiler ini memberikan lebih banyak peringatan dan kesalahan menarik daripada paket gcc sementara tidak membawa warisan yang sama dengan gcc.

2
Jawaban terbaik yang pernah ada!
Vorac

3
Sekadar informasi: GCC melacak ekspansi makro sejak 4.8, dengan opsi -ftrack-macro-expansion, sekarang diaktifkan secara default :)
Morwenn

Masalah lain dengan mencoba menyederhanakan struktur kode sumber pada waktu penguraian adalah bahwa ada banyak situasi di mana sedikit sintaksis tidak boleh menghasilkan kode apa pun tetapi harus memengaruhi optimasi apa yang diizinkan. Jika foodan mooadalah penunjuk ke tipe struktur yang berbeda, keduanya memiliki bidang barsebagai bagian dari urutan awal mereka, menulis *&foo->bardan membaca *&moo->barharus menghasilkan pembacaan melihat penulisan, karena satu-satunya jenis efektif yang digunakan dalam akses baik adalah jenis bar. GCC, bagaimanapun, tampaknya menyaring *&dan dengan demikian meresap jenis foodan moo...
supercat

... melalui alamat-operator, yang tidak dibenarkan oleh apa pun yang dapat saya temukan dalam Standar.
supercat

11

Alasan mengapa dibutuhkan banyak waktu adalah karena dibutuhkan banyak pekerjaan untuk mendapatkan dasar yang kuat untuk membangun header di atas. Cara mingw-w64 tampaknya bo adalah membangun pustaka seperti pthreads pada Windows. Ada sedikit kekasaran hulu dari itu daripada memperkenalkan ketergantungan pada threading asli Windows API.

mingw-w64 mengimplementasikan <thread>dan header C ++ 11 lainnya di atas winpthreadsperpustakaan mereka sendiri . Ini harus tersedia untuk pengujian dalam distribusi Mingw-builds dan rubenvb tentang toolchain mingw-w64. Saya akan merekomendasikan mengikuti milis mingw-w64 jika Anda ingin melacak di mana sebagian besar pekerjaan pada pekerjaan Windows GCC asli dilakukan.

Proyek Qt memiliki halaman wiki yang merinci rekomendasi mereka saat ini dan pandangan yang lebih luas dari toolchain GCC di windows, lihat halaman wiki Proyek Qt ini .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.