GCC có chết mà không có chủ đề hỗ trợ trên Windows không? [đóng cửa]

Tôi cần một số ý kiến. GCC luôn là một trình biên dịch rất tốt, nhưng gần đây nó đang mất "sự hấp dẫn". Tôi vừa thấy rằng trên Windows GCC không có std::threadhỗ trợ, buộc người dùng Windows phải sử dụng trình biên dịch khác vì tính năng thú vị nhất vẫn còn thiếu.

Nhưng tại sao GCC thực sự vẫn không hỗ trợ chủ đề trong Windows? Vấn đề giấy phép? ABI không tương thích? (Vâng, đã có một số thư viện đa nền tảng sử dụng đa luồng: boost, POCO, SDL, wxwidgets, v.v. không có hỗ trợ chủ đề?)

Gần đây, nhìn vào các so sánh trình biên dịch, GCC có sự hỗ trợ rộng nhất cho các tính năng của C ++ 11 so với các trình biên dịch khác, ngoại trừ thực tế là trên Windows, điều này không đúng vì chúng ta vẫn thiếu các nguyên tử, mutexes và thread: /

Tôi muốn biết thêm về chủ đề này, nhưng điều duy nhất tôi có thể tìm thấy là mọi người yêu cầu giúp đỡ vì:

"thread" không tồn tại trong không gian tên std

Nhìn vào theo dõi vé và thảo luận qua thư của GCC / TDM-GCC, đã có yêu cầu hỗ trợ luồng từ năm 2009. Có thể sau 4 năm vẫn không có giải pháp? Chuyện gì đang xảy ra vậy?

Tôi hiểu rằng GCC không được ủng hộ vì những người duy trì nó đã trở nên hơi kiêu ngạo và bây giờ LLVM ở đây (và rất tốt) mọi người đang bỏ phiếu bằng chân.

Slashdot đã có một cuộc thảo luận về hỗ trợ mới của LLVM cho C ++ 11 . _merlin nói:

Ồ tôi không nghĩ ai nghĩ nó xấu xa, chỉ là đó là lợi ích cá nhân thuần túy hơn là sự hào phóng. Sự phổ biến phi thường của GCC đã dẫn đến việc những người duy trì của nó phát triển bản ngã lớn và hành xử như tổng [ * *** ]. Lỗi được giới thiệu nhanh hơn Red Hat và Apple có thể nhận được các bản vá cho chúng được chấp nhận và chúng có thói quen khó chịu là không xem các báo cáo lỗi, sau đó đóng chúng do không hoạt động mà không thực sự sửa chúng

chuông báo với sự quan sát của bạn về sự chậm trễ 4 năm.

Sự phổ biến và khả năng sử dụng của GCC là không thể nghi ngờ.

• GCC vẫn là trình biên dịch tuyệt vời và được sử dụng rộng rãi nhất.
• GCC hỗ trợ các ngôn ngữ mà clang không nhắm đến, chẳng hạn như Java, Ada, FORTRAN, v.v.
• GCC hỗ trợ nhiều mục tiêu hơn LLVM.
• GCC đang hỗ trợ C ++ 11

Từ https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw xây dựng tại http://code.google.com.vn/p/mingw-builds/doads/list hỗ trợ chủ đề .

Nhưng xem xét quan trọng là Giấy phép.

• GCC được cấp phép theo giấy phép GPL. clang sử dụng giấy phép BSD, cho phép nó được nhúng trong phần mềm không được cấp phép GPL.
• Lý do chính để chuyển từ GCC sang Clang là sự không tương thích của giấy phép GPL v3 của GCC với các mục tiêu của dự án FreeBSD.

FreeBSD có mối quan hệ không thoải mái với GPL. Những người ủng hộ giấy phép BSD tin rằng phần mềm thực sự miễn phí không có hạn chế sử dụng. Những người ủng hộ GPL tin rằng các hạn chế là cần thiết để bảo vệ quyền tự do phần mềm và đặc biệt là khả năng tạo phần mềm không miễn phí từ phần mềm miễn phí là một hình thức quyền lực bất công hơn là tự do. Dự án FreeBSD, nếu có thể, cố gắng tránh sử dụng GPL (Để biết chi tiết https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- sẽ )

Những cân nhắc quan trọng khác

Từ http://clang.llvm.org/comparison.html#gcc

• Bất cứ ai quen thuộc với các ngôn ngữ liên quan và những người có hiểu biết cơ bản về cách thức hoạt động của trình biên dịch Clang ASTs đều có thể hiểu được dễ dàng. GCC có một cơ sở mã rất cũ thể hiện đường cong học tập dốc cho các nhà phát triển mới.
• Clang được thiết kế như một API từ khi thành lập, cho phép nó được sử dụng lại bởi các công cụ phân tích nguồn, tái cấu trúc, IDE (vv) cũng như để tạo mã. GCC được xây dựng như một trình biên dịch tĩnh nguyên khối, điều này khiến cho việc sử dụng như một API và tích hợp vào các công cụ khác trở nên vô cùng khó khăn. Hơn nữa, thiết kế lịch sử và chính sách hiện tại của nó làm cho khó có thể tách rời phần đầu ra khỏi phần còn lại của trình biên dịch.
• Nhiều quyết định thiết kế GCC khác nhau khiến việc sử dụng lại rất khó khăn: hệ thống xây dựng của nó rất khó sửa đổi, bạn không thể liên kết nhiều mục tiêu thành một nhị phân, bạn không thể liên kết nhiều giao diện thành một nhị phân, nó sử dụng trình thu gom rác tùy chỉnh, sử dụng rộng rãi các biến toàn cục, không phải là reentrant hoặc multi-threadable, v.v. Clang không có vấn đề nào trong số này.
• Đối với mỗi mã thông báo, clang theo dõi thông tin về nơi nó được viết và nơi cuối cùng được mở rộng thành nếu nó có liên quan đến một macro. GCC không theo dõi thông tin về việc khởi tạo macro khi phân tích mã nguồn. Điều này làm cho các công cụ viết lại nguồn (ví dụ để tái cấu trúc) rất khó hoạt động khi có các macro (thậm chí đơn giản).
• Clang không hoàn toàn đơn giản hóa mã vì nó phân tích cú pháp giống như GCC. Làm như vậy gây ra nhiều vấn đề cho các công cụ phân tích nguồn: như một ví dụ đơn giản, nếu bạn viết "xx" trong mã nguồn của mình, GCC AST sẽ chứa "0", không đề cập đến 'x'. Điều này cực kỳ tệ cho một công cụ tái cấu trúc muốn đổi tên 'x'.
• Clang có thể tuần tự AST của nó ra đĩa và đọc lại vào một chương trình khác, rất hữu ích cho việc phân tích toàn bộ chương trình. GCC không có điều này. Cơ chế PCH của GCC (chỉ là một bãi chứa hình ảnh bộ nhớ của trình biên dịch) có liên quan, nhưng về mặt kiến ​​trúc chỉ có thể đọc kết xuất trở lại chính xác như thực thi được tạo ra (nó không phải là định dạng có cấu trúc).
• Clang nhanh hơn nhiều và sử dụng bộ nhớ ít hơn nhiều so với GCC.
• Clang nhằm mục đích cung cấp chẩn đoán cực kỳ rõ ràng và súc tích (thông báo lỗi và cảnh báo), và bao gồm hỗ trợ cho chẩn đoán biểu cảm. Các cảnh báo của GCC đôi khi được chấp nhận, nhưng thường gây nhầm lẫn và nó không hỗ trợ chẩn đoán biểu cảm. Clang cũng bảo tồn typedefs trong chẩn đoán một cách nhất quán, cho thấy sự mở rộng vĩ mô và nhiều tính năng khác.
• Clang thừa hưởng một số tính năng từ việc sử dụng LLVM làm phụ trợ, bao gồm hỗ trợ biểu diễn mã byte cho mã trung gian, tối ưu hóa có thể cắm, hỗ trợ tối ưu hóa thời gian liên kết, biên dịch đúng lúc, khả năng liên kết trong nhiều trình tạo mã, v.v. .
• Hỗ trợ của Clang cho C ++ tuân thủ nhiều hơn GCC theo nhiều cách (ví dụ: tra cứu tên hai pha phù hợp).

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

• Ưu điểm của llvm / clang là thiết kế mô đun của nó, vì vậy nó có thể được
  giao thoa và sử dụng ví dụ để tạo các công cụ phân tích mã tĩnh, điều ngày càng trở nên quan trọng hơn ()

Từ http://clang.debian.net/

• clang hiện đã sẵn sàng để xây dựng phần mềm cho sản xuất (cho C, C ++ hoặc Objective-C). Trình biên dịch này đang cung cấp nhiều cảnh báo và lỗi thú vị hơn bộ gcc trong khi không mang cùng một di sản như gcc.

Lý do tại sao phải mất rất nhiều thời gian là bởi vì phải mất rất nhiều công sức để có được một nền tảng vững chắc để xây dựng các tiêu đề trên đầu trang. Cách mingw-w64 dường như bo là xây dựng một thư viện giống như pthreads trên Windows. Có ít sự cằn nhằn ngược dòng hơn là đưa ra sự phụ thuộc vào luồng gốc của API Windows.

mingw-w64 thực hiện <thread>và các tiêu đề C ++ 11 khác trên đầu winpthreadsthư viện của riêng họ . Điều này nên có sẵn để thử nghiệm trong cả hai bản phân phối Mingw-build và rubenvb của chuỗi công cụ mingw-w64. Tôi khuyên bạn nên theo dõi danh sách gửi thư mingw-w64 nếu bạn muốn theo dõi phần lớn công việc trên Windows GCC gốc được thực hiện.

Dự án Qt có một trang wiki mô tả chi tiết đề xuất hiện tại của họ và một cái nhìn toàn cảnh về các công cụ GCC trên các cửa sổ, xem trang wiki Qt Project này .