GCC กำลังจะตายโดยไม่มีเธรดรองรับบน Windows หรือไม่ [ปิด]

ฉันต้องการความคิดเห็น GCC เป็นคอมไพเลอร์ที่ดีอยู่เสมอ ฉันเพิ่งพบว่าบน Windows GCC ไม่มีstd::threadการสนับสนุนบังคับให้ผู้ใช้ Windows ใช้คอมไพเลอร์อื่นเพราะคุณสมบัติที่น่าตื่นเต้นที่สุดยังคงหายไป

แต่ทำไม GCC ถึงยังไม่มีการรองรับเธรดใน Windows ปัญหาใบอนุญาต? ABI เข้ากันไม่ได้? (มีห้องสมุดข้ามแพลตฟอร์มหลายแห่งที่ใช้มัลติเธรด: บูสต์, POCO, SDL, wxwidgets เป็นต้นมันไม่ง่ายเลยที่จะใช้ที่มีอยู่แล้วและ MIT / libpng ที่ได้รับอนุญาตรหัสเพื่อให้พอดีกับหลุมนี้แทนที่จะส่ง GCC ไม่มีการสนับสนุนเธรด?)

เมื่อเร็ว ๆ นี้เมื่อดูการเปรียบเทียบคอมไพเลอร์ GCC มีการรองรับคุณสมบัติ C ++ 11 ที่กว้างที่สุดในส่วนที่เกี่ยวกับคอมไพเลอร์อื่น ๆ ยกเว้นความจริงที่ว่าใน Windows นี้ไม่เป็นความจริงเพราะเรายังขาดอะตอมมิก mutexes และเธรด:

ฉันต้องการทราบเพิ่มเติมเกี่ยวกับหัวข้อนี้ แต่สิ่งเดียวที่ฉันสามารถหาได้คือคนที่ขอความช่วยเหลือเพราะ:

"thread" ไม่มีอยู่ใน std namespace

ดูการติดตามตั๋วและการสนทนาทางไปรษณีย์ของ GCC / TDM-GCC มีการร้องขอการสนับสนุนเธรดตั้งแต่ปี 2009 เป็นไปได้ไหมว่าหลังจาก 4 ปียังไม่มีวิธีแก้ปัญหา? เกิดอะไรขึ้นจริงเหรอ?

ฉันเข้าใจว่า GCC ไม่ได้รับความนิยมเพราะคนที่รักษามันค่อนข้างหยิ่งและตอนนี้ LLVM อยู่ที่นี่ (และดีมาก) ผู้คนโหวตด้วยเท้า

Slashdot มีการอภิปรายเกี่ยวกับการสนับสนุนใหม่ LLVM สำหรับ C _merlinพูดว่า:

โอ้ฉันไม่คิดว่าจะมีใครคิดว่ามันชั่วร้ายเพียงเพราะมันเป็นผลประโยชน์ส่วนตัวที่บริสุทธิ์มากกว่าความเอื้ออาทร ความนิยมในปรากฏการณ์ของ GCC ทำให้ผู้ดูแลระบบเติบโตอย่างมหาศาลและทำตัวเหมือนทั้งหมด [ * *** ] มีการแนะนำบั๊กเร็วกว่า Red Hat และ Apple สามารถรับ patch สำหรับพวกเขาได้รับการยอมรับและพวกเขามีนิสัยที่น่ารังเกียจที่จะไม่ดูรายงานบั๊กจากนั้นจึงปิดพวกมันเนื่องจากไม่มีการใช้งาน

สิ่งที่คุณสังเกตเห็นเกี่ยวกับความล่าช้า 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 คือความไม่ลงรอยกันของใบอนุญาต GPL v3 ของ GCC กับเป้าหมายของโครงการ 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/comparison.html#gcc

• Clang AST และการออกแบบนั้นมีวัตถุประสงค์เพื่อให้เข้าใจได้ง่ายโดยทุกคนที่คุ้นเคยกับภาษาที่เกี่ยวข้องและผู้ที่มีความเข้าใจพื้นฐานว่าคอมไพเลอร์ทำงานอย่างไร GCC มี codebase ที่เก่ามากซึ่งนำเสนอช่วงการเรียนรู้ที่สูงชันแก่นักพัฒนาใหม่
• เสียงดังกราวถูกออกแบบมาเป็น API จากจุดเริ่มต้นของมันช่วยให้มันสามารถนำมาใช้ใหม่โดยเครื่องมือการวิเคราะห์แหล่งที่มาการปรับโครงสร้าง IDEs (ฯลฯ ) รวมทั้งการสร้างรหัส GCC ถูกสร้างขึ้นเป็นคอมไพเลอร์สแตติกเสาหินซึ่งทำให้ยากมากที่จะใช้เป็น API และรวมเข้ากับเครื่องมืออื่น ๆ นอกจากนี้การออกแบบในอดีตและนโยบายปัจจุบันทำให้ยากต่อการแยกส่วนหน้าจากส่วนที่เหลือของคอมไพเลอร์
• การตัดสินใจออกแบบ GCC ต่างๆทำให้ยากต่อการนำกลับมาใช้ใหม่: ระบบการสร้างของมันยากที่จะแก้ไขคุณไม่สามารถเชื่อมโยงหลาย ๆ เป้าหมายกับหนึ่งไบนารี่ได้ แต่คุณไม่สามารถเชื่อมโยงหลาย ๆ หน้าเข้ากับหนึ่งไบนารี่ได้ ใช้ตัวแปรทั่วโลกอย่างกว้างขวางไม่ใช่ reentrant หรือหลายเธรด ฯลฯ เสียงดังกราวไม่มีปัญหาเหล่านี้
• สำหรับทุกโทเค็นเสียงดังกราวจะติดตามข้อมูลเกี่ยวกับตำแหน่งที่มันถูกเขียนและที่ที่มันถูกขยายเข้าไปในท้ายที่สุด GCC ไม่ติดตามข้อมูลเกี่ยวกับการสร้างอินสแตนซ์ของแมโครเมื่อแยกวิเคราะห์ซอร์สโค้ด สิ่งนี้ทำให้เป็นเรื่องยากมากสำหรับเครื่องมือการเขียนซอร์สใหม่ (เช่นสำหรับการปรับโครงสร้างใหม่) เพื่อทำงานต่อหน้าแมโคร (แม้แต่ง่าย)
• เสียงดังกังวานไม่ได้ทำให้รหัสง่ายขึ้นโดยง่ายเพราะมันแยกวิเคราะห์เหมือนกับ GCC การทำเช่นนี้ทำให้เกิดปัญหามากมายสำหรับเครื่องมือวิเคราะห์แหล่งที่มา: เป็นตัวอย่างง่ายๆอย่างหนึ่งถ้าคุณเขียน "xx" ในซอร์สโค้ดของคุณ GCC AST จะมี "0" โดยไม่มีการกล่าวถึง 'x' สิ่งนี้ไม่ดีอย่างยิ่งสำหรับเครื่องมือการเปลี่ยนโครงสร้างที่ต้องการเปลี่ยนชื่อ 'x'
• เสียงดังกังวานสามารถเรียงลำดับ AST ออกไปยังดิสก์และอ่านกลับเข้าไปในโปรแกรมอื่นซึ่งเป็นประโยชน์สำหรับการวิเคราะห์โปรแกรมทั้งหมด GCC ไม่มีสิ่งนี้ กลไก PCH ของ GCC (ซึ่งเป็นเพียงดัมพ์ของอิมเมจหน่วยความจำคอมไพเลอร์) นั้นมีความสัมพันธ์กัน แต่เป็นสถาปัตยกรรมที่สามารถอ่านดัมพ์กลับไปสู่การปฏิบัติการที่แน่นอนเหมือนกับที่สร้างขึ้นมา (ไม่ใช่รูปแบบที่มีโครงสร้าง)
• เสียงดังกราวนั้นเร็วกว่ามากและใช้หน่วยความจำน้อยกว่า GCC
• เสียงดังกราวมีวัตถุประสงค์เพื่อให้การวินิจฉัยที่ชัดเจนและรัดกุมมาก (ข้อผิดพลาดและข้อความเตือน) และรวมถึงการสนับสนุนสำหรับการวินิจฉัยที่แสดงออก คำเตือนของ GCC บางครั้งเป็นที่ยอมรับได้ แต่มักทำให้เกิดความสับสนและไม่สนับสนุนการวินิจฉัยที่ชัดเจน เสียงดังกังวานยังคงรักษา typedefs ในการวินิจฉัยอย่างต่อเนื่องแสดงการขยายมาโครและคุณสมบัติอื่น ๆ อีกมากมาย
• เสียงดังกังวานสืบทอดคุณสมบัติหลายประการจากการใช้ LLVM เป็นแบ็คเอนด์รวมถึงการสนับสนุนการเป็นตัวแทน bytecode สำหรับรหัสกลาง, เครื่องมือเพิ่มประสิทธิภาพแบบเสียบได้, การสนับสนุนการเพิ่มประสิทธิภาพเวลาเชื่อมโยง, การคอมไพล์ Just-In-Time, ความสามารถในการเชื่อมโยง .
• การสนับสนุนของ Clang สำหรับ 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 suite ในขณะที่ไม่ได้รับมรดกเช่นเดียวกับ gcc

เหตุผลที่ต้องใช้เวลามากเพราะมันต้องใช้เวลามากในการสร้างรากฐานที่แข็งแกร่งในการสร้างส่วนหัว ดูเหมือนว่า mingw-w64 จะทำคือการสร้างไลบรารี่ที่เหมือน pthreads บน Windows มีความไม่พอใจอัปสตรีมน้อยกว่าการแนะนำการพึ่งพาการทำเธรดดั้งเดิมของ Windows API

mingw-w64 ดำเนินการ<thread>และส่วนหัว C ++ 11 อื่น ๆ ที่ด้านบนของwinpthreadsห้องสมุดของพวกเขาเอง สิ่งนี้ควรจะพร้อมใช้งานสำหรับการทดสอบในทั้งการกระจายของ Mingw-builds และ rubenvb ของ tooling mingw-w64 ฉันอยากจะแนะนำต่อไปนี้รายชื่อผู้รับจดหมาย mingw-w64 หากคุณต้องการติดตามว่างานส่วนใหญ่ในงาน Windows GCC แบบดั้งเดิมเสร็จสิ้นแล้ว

โครงการ Qt มีหน้าวิกิพีเดียรายละเอียดคำแนะนำปัจจุบันของพวกเขาและมองเห็นวิวของ toolchains GCC หน้าต่างดูหน้านี้วิกิพีเดีย Qt โครงการ