क्या विंडोज पर थ्रेड्स के बिना जीसीसी मर रहा है? [बन्द है]

Question

मुझे कुछ राय चाहिए। जीसीसी हमेशा एक बहुत अच्छा संकलक था, लेकिन हाल ही में यह "अपील" खो रहा है। मैंने अभी पाया है कि विंडोज पर जीसीसी का std::threadसमर्थन नहीं है , विंडोज उपयोगकर्ताओं को एक और संकलक का उपयोग करने के लिए मजबूर करना क्योंकि सबसे रोमांचक सुविधा अभी भी गायब है।

लेकिन वास्तव में जीसीसी के पास विंडोज के तहत थ्रेड्स का समर्थन क्यों नहीं है? लाइसेंस की समस्या? ABI की असंगतियाँ? (वैसे मल्टीथ्रेडिंग का उपयोग करने वाले पहले से ही कई क्रॉस-प्लेटफॉर्म लाइब्रेरी हैं: बूस्ट, POCO, SDL, wxwidgets, आदि। यह पहले से मौजूद मौजूदा का उपयोग करने के लिए सरल नहीं होगा, और MIT / libpng लाइसेंस प्राप्त है, कोड शिपिंग जीसीसी रिलीज के बजाय इस छेद को फिट करने के लिए कोई धागा समर्थन के साथ?)

हाल ही में, कंपाइलर की तुलना को देखते हुए, जीसीसी को अन्य कंपाइलरों के संबंध में C ++ 11 सुविधाओं के लिए सबसे बड़ा समर्थन है, इस तथ्य के अलावा कि विंडोज पर यह सच नहीं है क्योंकि हमारे पास अभी भी एटमिक्स, म्यूटेक्स और थ्रेड्स की कमी है:

मैं इस विषय के बारे में अधिक जानना चाहता हूं, लेकिन केवल एक चीज जो मुझे मिल सकती है वह है लोग मदद के लिए पूछ रहे हैं:

"थ्रेड" std नाम स्थान में मौजूद नहीं है

जीसीसी / टीडीएम-जीसीसी के टिकट ट्रैकिंग और मेल चर्चाओं को देखते हुए, 2009 के बाद से थ्रेड समर्थन के लिए अनुरोध किए गए थे। संभव है कि 4 साल बाद भी कोई समाधान न हो? वास्तव में क्या हो रहा है?

Comments

gcc अभी भी अच्छा है, चाहे आपको हाल ही में पता चला हो।

— ott--

मुझे सिर्फ std :: धागा पसंद है। इसे लागू करने के लिए इतनी कठिन सुविधा नहीं थी। बस varadics टेम्प्लेट लें और उदाहरण के लिए SDL थ्रेड और आप std के बराबर एक क्लास बना सकते हैं :: थ्रेड: /

— GameDeveloper

मैं विश्वसनीय मल्टी-थ्रेडेड ऐप्स लिखने के लिए औसत प्रोग्रामर की अक्षमता को लगभग तर्क दूंगा, कोई थ्रेड सपोर्ट बोनस नहीं है .....

— मैट्टनज़ २१'१३

आप परिवादियों के बारे में शिकायत कर रहे हैं विशेष रूप से संकलक नहीं।

— सिरबेल

जीसीसी लोकप्रिय है, यह सच है। लेकिन मैं यह नहीं कहूंगा कि यह हमेशा "एक बहुत अच्छा संकलक" रहा है। एजेस पहले लोग लिनक्स पर ICC के साथ प्रयोग कर रहे थे, क्योंकि धीमी और फूला हुआ बायनेरिज़ जो GCC द्वारा उत्पादित की गई थी। ओटीओएच, सभी प्रमुख ओपन सोर्स प्रोजेक्ट अपने कोड के विंडोज संस्करण को संकलित करने के लिए वीएस का उपयोग करते हैं, फिर से, क्योंकि जीसीसी तुलना में धीमे ब्लोट का उत्पादन करता है।

— vartec

Answer 1

मैं समझ गया कि जीसीसी पक्ष से बाहर हो रहा है क्योंकि इसे बनाए रखने वाले लोग कुछ हद तक अभिमानी हो गए हैं, और अब जब एलएलवीएम यहां है (और बहुत अच्छा है) लोग पैरों से वोट दे रहे हैं।

Slashdot ने LLVM के C ++ 11 के नए समर्थन के बारे में चर्चा की । _merlin कहते हैं:

ओह, मुझे नहीं लगता कि किसी को लगता है कि यह बुराई है, बस यह उदारता के बजाय शुद्ध स्वार्थ है। जीसीसी की अभूतपूर्व लोकप्रियता के कारण इसके रखवाले बड़े पैमाने पर एगोस बढ़ रहे हैं और कुल [ * *** ] की तरह व्यवहार कर रहे हैं । Red Hat की तुलना में बग्स को तेज़ी से पेश किया जाता है और Apple उन्हें स्वीकार किए जाने के लिए पैच प्राप्त कर सकता है, और उन्हें बग रिपोर्ट देखने की बुरी आदत है, फिर वास्तव में उन्हें ठीक किए बिना निष्क्रियता के कारण उन्हें बंद करना

जो 4 साल की देरी के बारे में आपके अवलोकन के साथ झंकार करता है।

Comments

आप यह भी हो सकता है developers.slashdot.org/... जीसीसी के साथ गैर लिनक्स के लिए संकलन के साथ अन्य समस्याओं को बताते (भी _merlin द्वारा)।

यह सिर्फ एलएलवीएम नहीं है, विजुअल स्टूडियो एक्सप्रेस संस्करण एक और व्यवहार्य, मुफ्त विकल्प है (प्रश्न पर विशेष रूप std::threadसे विंडोज के बारे में है जो वीएस2012 ईई में समर्थित है)

— MSalters

बहुत खराब VS2012 में std :: थ्रेड के लिए पूर्ण समर्थन नहीं है (जैसे कोई thread_localचर नहीं )

— alrikai

क्या आधुनिक समय में यह बिल्कुल बदल गया है?

— हाशिम

Answer 2

जीसीसी की लोकप्रियता और उपयोगिता संदिग्ध नहीं है।

• जीसीसी अभी भी महान संकलक है और सबसे अधिक व्यापक रूप से उपयोग किया जाता है।
• जीसीसी उन भाषाओं का समर्थन करता है जो क्लैंग को लक्ष्य नहीं करती हैं, जैसे जावा, एडा, फोरट्रान, आदि।
• जीसीसी एलएलवीएम की तुलना में अधिक लक्ष्यों का समर्थन करता है।
• GCC C ++ 11 का समर्थन कर रहा है

से https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads MinGW निर्माण पर http://code.google.com/p/mingw-builds/downloads/list धागे का समर्थन करता है ।

लेकिन महत्वपूर्ण विचार लाइसेंस है।

• GCC को GPL लाइसेंस के तहत लाइसेंस प्राप्त है। क्लैंग एक बीएसडी लाइसेंस का उपयोग करता है, जो इसे सॉफ्टवेयर में एम्बेड करने की अनुमति देता है जो कि जीपीएल-लाइसेंस नहीं है।
• जीसीसी से क्लैंग में स्विच करने का प्राथमिक कारण फ्रीबीएसडी परियोजना के लक्ष्यों के साथ जीसीसी के जीपीएल वी 3 लाइसेंस की असंगति है।

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

• क्लैंग एएसटी और डिज़ाइन का उद्देश्य किसी के द्वारा आसानी से समझा जा सकता है जो इसमें शामिल भाषाओं से परिचित है और जिनके पास कंपाइलर कैसे काम करता है इसकी बुनियादी समझ है। जीसीसी में एक बहुत पुराना कोडबेस है जो नए डेवलपर्स के लिए एक मजबूत सीखने की अवस्था प्रस्तुत करता है।
• क्लैंग को इसकी स्थापना से एपीआई के रूप में डिज़ाइन किया गया है, इसे स्रोत विश्लेषण उपकरण, रीफैक्टरिंग, आईडीई (आदि) और साथ ही कोड पीढ़ी के लिए पुन: उपयोग करने की अनुमति देता है। जीसीसी को एक अखंड स्थिर संकलक के रूप में बनाया गया है, जो एपीआई के रूप में उपयोग करना और अन्य उपकरणों में एकीकृत करना बहुत कठिन बनाता है। इसके अलावा, इसकी ऐतिहासिक डिजाइन और वर्तमान नीति बाकी कंपाइलर के सामने के छोर को अलग करना मुश्किल बनाती है।
• विभिन्न जीसीसी डिजाइन निर्णय पुन: उपयोग करना बहुत मुश्किल बनाते हैं: इसकी निर्माण प्रणाली को संशोधित करना मुश्किल है, आप कई लक्ष्यों को एक बाइनरी में लिंक नहीं कर सकते हैं, आप कई फ्रंट-एंड को एक बाइनरी में लिंक नहीं कर सकते हैं, यह एक कस्टम कचरा कलेक्टर का उपयोग करता है, बड़े पैमाने पर वैश्विक चर का उपयोग करता है, रीएन्स्ट्रेंट या मल्टी-थ्रेडेबल नहीं है, आदि क्लेंग में इन समस्याओं में से कोई भी नहीं है।
• प्रत्येक टोकन के लिए, क्लैंग जानकारी के बारे में जानकारी देता है कि यह कहाँ लिखा गया था और यह अंततः एक मैक्रो में शामिल होने पर विस्तारित किया गया था। स्रोत कोड को पार्स करते समय GCC मैक्रो इंस्टेंटेशन के बारे में जानकारी को ट्रैक नहीं करता है। यह (यहां तक ​​कि सरल) मैक्रोज़ की उपस्थिति में काम करने के लिए स्रोत पुनर्लेखन उपकरण (उदाहरण के लिए) के लिए बहुत मुश्किल बनाता है।
• क्लैंग ने कोड को सरलता से नहीं बताया क्योंकि यह जीसीसी करता है। ऐसा करने से स्रोत विश्लेषण उपकरणों के लिए कई समस्याएं पैदा होती हैं: एक सरल उदाहरण के रूप में, यदि आप अपने स्रोत कोड में "xx" लिखते हैं, तो GCC AST में "0" होगा, जिसमें 'x' का कोई उल्लेख नहीं है। यह एक रीफैक्टरिंग टूल के लिए बेहद खराब है जो 'x' का नाम बदलना चाहता है।
• क्लैंग अपने एएसटी को डिस्क से क्रमबद्ध कर सकता है और इसे वापस दूसरे प्रोग्राम में पढ़ सकता है, जो पूरे प्रोग्राम विश्लेषण के लिए उपयोगी है। जीसीसी के पास यह नहीं है। जीसीसी का पीसीएच तंत्र (जो कि कंपाइलर मेमोरी इमेज का सिर्फ एक डंप है) संबंधित है, लेकिन वास्तुशिल्प रूप से डंप को केवल उसी निष्पादन योग्य में वापस पढ़ने में सक्षम है जैसा कि इसे उत्पादित करने वाला (यह एक संरचित प्रारूप नहीं है)।
• क्लैंग बहुत तेज है और जीसीसी की तुलना में बहुत कम मेमोरी का उपयोग करता है।
• क्लैंग का लक्ष्य अत्यंत स्पष्ट और संक्षिप्त निदान (त्रुटि और चेतावनी संदेश) प्रदान करना है, और इसमें अभिव्यंजक निदान के लिए समर्थन शामिल है। जीसीसी की चेतावनी कभी-कभी स्वीकार्य होती है, लेकिन अक्सर भ्रमित होती है और यह अभिव्यंजक निदान का समर्थन नहीं करती है। क्लैंग लगातार डायग्नोस्टिक्स में टाइपिडिफ को भी संरक्षित करता है, मैक्रो विस्तार और कई अन्य विशेषताओं को दर्शाता है।
• क्लैंग ने एलएलवीएम के उपयोग से बैकएंड के रूप में कई विशेषताओं को विरासत में लिया है, जिसमें इंटरमीडिएट कोड के लिए बायोटेक प्रतिनिधित्व, प्लग-योग्य ऑप्टिमाइज़र, लिंक-टाइम ऑप्टिमाइज़ेशन समर्थन, जस्ट-इन-टाइम संकलन, कई कोड जनरेटर में लिंक करने की क्षमता आदि का समर्थन शामिल है। ।
• C ++ के लिए Clang का समर्थन कई तरीकों से GCC की तुलना में अधिक आज्ञाकारी है (उदाहरण के लिए दो चरण नाम देखने के अनुरूप)।

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

• Llvm / clang का लाभ इसका मॉड्यूलर डिजाइन है, इसलिए इसे
  स्थिर कोड विश्लेषण उपकरण बनाने के लिए उदाहरण के लिए इस्तेमाल किया जा सकता है, जो कि अधिक से अधिक महत्वपूर्ण हो जाता है ()

से http://clang.debian.net/

• क्लैंग अब उत्पादन के लिए सॉफ्टवेयर बनाने के लिए तैयार है (या तो C, C ++ या Objective-C के लिए)। यह संकलक gcc सुइट की तुलना में कई अधिक चेतावनियाँ और दिलचस्प त्रुटियाँ प्रदान कर रहा है जबकि gcc के समान विरासत को नहीं ले जा रहा है।

Comments

सबसे अच्छा जवाब कभी!

— वोरैक

सिर्फ अप-टू-डेट होने के लिए: जीसीसी 4.8 के बाद से मैक्रोज़ के विस्तार को ट्रैक करता है -ftrack-macro-expansion, विकल्प के साथ , अब डिफ़ॉल्ट रूप से सक्षम है :)

— मोरविन

पार्सिंग समय पर स्रोत के पेड़ को सरल बनाने की कोशिश करने के साथ एक और समस्या यह है कि ऐसी कई परिस्थितियां हैं जहां थोड़ा सा वाक्यविन्यास किसी भी कोड को उत्पन्न नहीं करना चाहिए लेकिन यह प्रभावित करना चाहिए कि क्या अनुकूलन की अनुमति है। यदि fooऔर mooविभिन्न संरचना प्रकारों के संकेत हैं, तो दोनों में barउनके प्रारंभिक अनुक्रम के हिस्से के रूप में फ़ील्ड है , लेखन *&foo->barऔर पढ़ने *&moo->barका परिणाम लेखन को देखने में पढ़ने के परिणामस्वरूप होना चाहिए, क्योंकि दोनों के उपयोग में एकमात्र प्रभावी प्रकार का प्रकार है bar। GCC, हालांकि, बाहर फ़िल्टर करने के लिए लगता है *&और इस प्रकार के रूप में percolates fooऔर moo...

— Supercat

... ऑपरेटर के पते के माध्यम से, जो कि मैं मानक में पाया जा सकता है कुछ भी द्वारा उचित नहीं है।

— सुपरकैट

Answer 3

कारण यह है कि यह बहुत समय लगता है क्योंकि शीर्ष पर शीर्ष लेख बनाने के लिए एक ठोस नींव प्राप्त करने में बहुत काम लगता है। जिस तरह से mingw-w64 को लगता है कि विंडोज पर एक ठोस pthreads जैसी लाइब्रेरी का निर्माण करना है। विंडोज एपीआई के मूल थ्रेडिंग पर निर्भरता शुरू करने की तुलना में उस पर कम अपस्ट्रीम का आभास होता है।

mingw-w64 लागू <thread>और अपने स्वयं के winpthreadsपुस्तकालय के शीर्ष पर अन्य सी ++ 11 हेडर । यह मिंगव-बिल्ड और रेनबॉब के मिंगव-डब्ल्यू 64 टूलचिन के वितरण में दोनों के परीक्षण के लिए उपलब्ध होना चाहिए। यदि आप यह ट्रैक करना चाहते हैं तो मैं मिंगवॉ-डब्ल्यू 64 मेलिंग सूचियों का पालन करने की सलाह दूंगा जहां देशी विंडोज जीसीसी के अधिकांश काम किए जाते हैं।

Qt प्रोजेक्ट में एक विकी पेज है, जो उनकी वर्तमान अनुशंसा और खिड़कियों पर GCC टूलकिन के दृश्य को देखते हुए, इस Qt प्रोजेक्ट विकी पेज को देखता है ।