क्या सी ++ विकास में एसटीएल को छोड़ना व्यावहारिक है? [बन्द है]

19

बंद हो गया । इस प्रश्न पर अधिक ध्यान देने की आवश्यकता है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि यह इस पोस्ट को संपादित करके केवल एक समस्या पर केंद्रित हो ।

4 साल पहले बंद हुआ ।

मुझे कुछ क्षेत्रों में पता है (खेल उद्योग, उदाहरण के लिए), एसटीएल अनुशंसित नहीं है। तो मेरा सवाल यह है कि क्या कुछ मामलों में एसटीएल का उपयोग नहीं करना वास्तव में एक अच्छा अभ्यास है? यदि हां, तो आधुनिक C ++ के STL का उपयोग न करने का सबसे बड़ा कारण क्या है?

c++ stl

— CaptainJH
स्रोत

संबंधित प्रश्न

— fredoverflow

मेरे कुछ सहयोगियों का तर्क है कि, इट्रेटर कठिन डिबगिंग बनाता है, क्योंकि कभी-कभी यह आसान नहीं होता है, और यह भी लैम्ब्डा पर लागू होता है। आपकी क्या प्रतिक्रिया है?

— कप्तानजेएच

डिबगिंग के दौरान सामान लंघन के लिए, उदाहरण के लिए, देखें: stackoverflow.com/questions/2062881/…

— मार्टिन बा

यह एक अच्छा प्रश्न लगता है। शायद कोई व्यक्ति यह कह सकता है कि "कोई परियोजना एसटीएल का उपयोग क्यों नहीं करेगी?"

— मैथ्यू जेम्स ब्रिग्स

25

मैं केवल एक वैध कारण के बारे में सोच सकता हूं और यह वास्तव में दुर्लभ है: कठिन वास्तविक समय। मानक पुस्तकालय में कई चीजें आंतरिक रूप से मेमोरी आवंटित करती हैं और यह कठिन वास्तविक समय के अनुप्रयोगों के लिए पर्याप्त रूप से निर्धारित नहीं है, इसलिए उन्हें बचा जाना चाहिए। ये अनुप्रयोग आम तौर पर काफी सरल होते हैं, हालांकि वे बहुत कठोर समीक्षा और परीक्षण के कारण विकसित होने के लिए विषम समय लेते हैं।
मैं एक अमान्य, लेकिन बहुत सामान्य कारण के बारे में सोच सकता हूं: डेवलपर्स जो कम्प्यूटेशनल जटिलता को नहीं समझते हैं, एसटीएल का दुरुपयोग करते हैं और फिर पुस्तकालय को दोष देते हैं।

एसटीएल आमतौर पर कॉलबैक पॉइंटर्स या पॉलीमॉर्फिज्म-आधारित समाधानों के साथ आभासी तरीकों के साथ सी-स्टाइल समाधानों की तुलना में रनटाइम पर अधिक तेज होता है ( यह भी देखें कि यह ब्रेज़ेन स्ट्रॉस्ट्रुप की कुंजी है )। हालाँकि जब डेवलपर दी गई जटिलता के विनिर्देशों को नहीं समझता है और कुछ जटिल वस्तुओं के वैक्टर की तरह कुछ बनाकर पुस्तकालय का दुरुपयोग करता है (C ++ 11 में यह अब समस्या नहीं है, हालांकि!), प्रदर्शन समस्या का कारण बन सकता है और अपने बचाव के बजाय। "आप देखते हैं, वैक्टर धीमे हैं", यह एक धारणा का कारण बन सकता है कि मानक पुस्तकालय धीमा है। और एक बार प्रबंधकों को ऐसी धारणा मिल जाती है, तो यह संगठन में बहुत लंबे समय तक रह सकता है।
जाहिर है आप किसी भी ऐसी चीज का उपयोग नहीं कर सकते हैं जिसे आप लक्षित कर रहे हैं, वह समर्थन नहीं करती है। हालाँकि हम वर्तमान में चार सबसे आम मोबाइल प्लेटफार्मों (Android, iOS, Bada और पुराने WinCE) को लक्षित कर रहे हैं और उन सभी पर मानक पुस्तकालय और बूस्ट के कुछ हिस्सों का उपयोग करते हैं।

Microsoft द्वारा WinCE (IIRC iostreams केवल विजुअल स्टूडियो 2005 के साथ सामने आया) में बहुत से मानक पुस्तकालय असमर्थित थे, लेकिन इसके बजाय बहुत पहले STLport का उपयोग करना संभव था । और आप आमतौर पर किसी भी चीज़ को संकलित कर सकते हैं। इसलिए मैं इस कारण को भी अमान्य कहूंगा।

इसके अलावा, काफी समय से यह "एसटीएल" नहीं है, लेकिन एएनएसआई सी ++ मानक पुस्तकालय है। यह उसी मानक दस्तावेज़ द्वारा परिभाषित किया गया है जो भाषा को ही परिभाषित करता है। जो कुछ भी इसका समर्थन नहीं करता है वह वास्तव में C ++ कहलाने के लायक नहीं है।

— जान हुदेक
स्रोत

6

पहला तर्क (रीयलटाइम) मानक लाइब्रेरी के एसटीएल भागों के लिए विशिष्ट नहीं है। sprintfअक्सर मेमोरी भी आवंटित करता है। रीयलटाइम प्लेटफ़ॉर्म पर, मानक लाइब्रेरी फ़ंक्शंस में नियतात्मक सीमाएं भी होती हैं। यह रीयलटाइम C ++ कार्यान्वयन को कठिन बनाता है: आपको सावधानीपूर्वक पूरे C ++ मानक पुस्तकालय को विकसित करना होगा, जो कि केवल छोटे मानक पुस्तकालय की तुलना में अधिक काम है।

— MSALERS

@MSalters: निश्चित रूप से, कई चीजों का उपयोग वास्तविक समय की आवश्यकताओं के तहत नहीं किया जा सकता है। यहां तक कि कुछ भाषा सुविधाएँ जैसे अपवाद नहीं हो सकते। फिर भी C ++ इन प्रणालियों के लिए महान भाषा है, क्योंकि यह मजबूत सुरक्षा उपायों के साथ प्रदर्शन और सटीक नियंत्रण को मिला सकती है (RAII उस के लिए सबसे महत्वपूर्ण विशेषता है)।

— Jan Hudec

@ जैनधेक: वास्तव में, यही कारण है कि एसटीएल भागों को केवल C ++ के "होस्टेड" कार्यान्वयन के लिए आवश्यक है।

— एमएसलेट्स

7

मैं एसटीएल का उपयोग कर रहा हूं और पहले से ही कई वर्षों से बढ़ावा दे रहा हूं। अगर मैं इसे छोड़ना चाहता हूं और अपने कस्टम टूल का उपयोग करना चाहता हूं, तो प्रेरणा होगी:

संकलन समय में कमी (75%)। Iostreams सहित, आपके मॉड्यूल में कोड की 1 मिलियन लाइनें जोड़ सकते हैं। हाँ precompiled हेडर बहुत मदद करते हैं, लेकिन यह अभी भी संकलन को बड़ी परियोजनाओं में धीमा कर देता है। लंबे समय में, यह उस पर काम करने वाले किसी भी व्यक्ति का बहुत समय बर्बाद करता है।
प्रदर्शन। (25%) एसटीएल को आम तौर पर काम करने के लिए लिखा जाता है, लेकिन आप अपनी संरचनाओं को ठीक उसी तरह काम करने के लिए अनुकूलित कर सकते हैं जैसा आप चाहते हैं। उदाहरण के लिए, आपके पास लाखों छोटी स्ट्रिंग्स के साथ एक डेटा संरचना हो सकती है। बढ़ावा देने के मूल के आधार पर कस्टम स्ट्रिंग क्लास का उपयोग करना अधिक तेज़ हो सकता है :: small_vector (डेटा का छोटा स्थिर स्थानीय वेक्टर, केवल बड़े स्ट्रिंग्स के लिए डायनेमिक आवंटन), इस प्रकार के परिवर्तन कोड के महत्वपूर्ण अनुभागों को कई बार तेजी से काम कर सकते हैं।

— Marwin
स्रोत

1

SSO पहले से ही सामान्य है।

— डिडुप्लिकेटर

पश्चात के लिए: एसएसओ -> छोटे स्ट्रिंग अनुकूलन, यानी सबसे (सभी?) एसटीडी: स्ट्रिंग कार्यान्वयन स्टैक पर छोटे तार रखते हैं और यदि आवश्यक हो तो ढेर पर स्विच करें

— नीला

संकलन समय एक बड़ा है

— user1754322

4

C ++ मानक टेम्प्लेट लाइब्रेरी का उपयोग न करने का एक बड़ा वैध कारण है: आपके किसी लक्षित प्लेटफ़ॉर्म में इसका पूर्ण रूप से अनुरूप कार्यान्वयन नहीं है (या इसका कोई कार्यान्वयन नहीं है) और आप जानते हैं कि यह एक नहीं होगा अगले वर्षों के भीतर।

— पैट्रिक
स्रोत

3

अका "जब आपके पास नहीं है तो इसका उपयोग न करें", जो वास्तव में समझ में आता है। :)

— Xio

4

यह देखते हुए कि C ++ 03 मानक पुस्तकालय को केवल ANSI C89 पुस्तकालय के संदर्भ में लागू करने के लिए डिज़ाइन किया गया है, क्या कोई ऐसा प्लेटफ़ॉर्म है जहाँ आपको कम से कम STLPort नहीं मिल सकता है ?

— Jan Hudec

@ जानहुडेक मेरा मानना है कि एसटीएल के बिना प्लेटफार्म हैं क्योंकि उनके पास पूरी चीज़ को संभालने के लिए पर्याप्त मेमोरी नहीं है। आमतौर पर वे कुछ अन्य सी ++ कार्यक्षमता (जैसे अपवाद) भी याद कर रहे हैं।

— सुल्तान

2

@ सुल्तान: माइक्रोकंट्रोलर के लिए मैं एक तरह का समझ रहा हूं, लेकिन आमतौर पर "कठिन रीयलटाइम" श्रेणी में आते हैं। किसी और चीज के लिए, यह ज्यादातर पूर्व धारणाएं हैं, क्योंकि एसटीएल आमतौर पर स्मृति और प्रदर्शन-वार दोनों के रूप में कुशल होता है, जो हाथ से तैयार किए गए कोड के रूप में होता है। बहुत सारे इनलाइनिंग बाइनरी का कारण बन सकते हैं, लेकिन यह भी कुछ प्रदर्शन लागत पर सावधानीपूर्वक कार्यान्वयन से बचा जा सकता है (कि एक हाथ से तैयार समाधान भी होगा)। मिसिंग अपवाद या तो पूर्वधारणा है, या आलस्य है, क्योंकि यह अपवाद एबीआई को परिभाषित करने और लागू करने का प्रयास करता है।

— Jan Hudec

4

मुझे जटिलता (कार्यान्वयन की दक्षता) के बारे में नहीं पता है लेकिन मैं क्यूटी कंटेनरों और स्ट्रिंग्स का उपयोग बड़े पैमाने पर कर रहा हूं क्योंकि वे एसटीडी वाले हैं और वे ठीक काम करते हैं। मुझे सेट का Qt कार्यान्वयन और उपयोग करने के लिए आसान सूचियों का भी पता चलता है।

इसलिए, एसटीएल को छोड़ना व्यावहारिक हो सकता है यदि आप किसी अन्य पुस्तकालय का उपयोग कर सकते हैं जो आपकी आवश्यकताओं के अनुरूप है।

— जियोर्जियो
स्रोत

2

जब कोई एसटीएल कार्यान्वयन उपलब्ध नहीं थे तो क्यूटी समकक्षों को वापस बनाया गया था जो कि ए) उपलब्ध थे, या बी) कोई अच्छा। यही एकमात्र कारण है कि वे अभी भी उपयोग किए जाते हैं, आज के एसटीएल के खिलाफ कुछ भी नहीं।

— gbjbaanb

1

@ जियोर्जियो: समस्या जटिल अनुप्रयोगों में है, जहां आप कई पुस्तकालयों का संयोजन कर रहे हैं। एसटीएल कंटेनर, मानक होने के नाते, एक लिंगुआ फ्रेंका बनाते हैं । अधिक सटीक रूप से, यह उनकी परंपराएं हैं जो करते हैं। सबसे प्रसिद्ध उदाहरण बूस्ट है। यह एसटीएल कंटेनरों पर काम कर सकता है। यह Qt कंटेनरों पर भी काम कर सकता है, लेकिन केवल इसलिए कि Qt ने STL सम्मेलनों का अनुसरण किया है - जैसेQList<T>::iterator

— MSalters

3

मैंने इसे कम नहीं किया, लेकिन मुझे एक कारण दिखाई देता है: यह सवाल का जवाब नहीं देता है। आपने कहा कि एसटीएल के बजाय उपयोग करने के लिए चीजें हैं, ठीक है, लेकिन यह एसटीएल से बचने का एक कारण नहीं है। एसटीएल से बचने के किसी भी कारण के अलावा संभवतः क्यूटी, एमएफसी और अन्य ऐसे पुस्तकालयों पर भी लागू होता है।

— जन हडेक

3

@ नोनी: हम जानते हैं कि आप ऊंट के लिए उपयोग किए जाते हैं, न कि स्नेककेस, लेकिन यह बाद को किसी भी बदतर नहीं बनाता है। और जिन तीन फ़ंक्शन-नामों की आप आलोचना करते हैं, उनमें से किसी को सी-स्ट्रिंग्स के साथ कुछ भी करने के लिए पूरी तरह से वर्णनात्मक है, और अन्य दो सी से विरासत में मिले हैं, उन पर चर्चा नहीं करेंगे।

— डिडुप्लीकेटर 14

1

@ नोऑन: जैसा कि मैंने कहा, मुझे पूरी तरह से पता है कि आप कैमलकेस के साथ अधिक सहज हैं।

— डिडुप्लिकेटर

3

पैट्रिक ने पूरे एसटीएल का उपयोग न करने के कारण का उल्लेख किया है, अर्थात् आपके प्लेटफ़ॉर्म में एक नहीं है।

सब मुझे लगता है कि सवाल बिंदु याद आ रही है। यह ज्यादातर एक या सभी निर्णय नहीं है, लेकिन पिक और चुनने में से एक है। आप अच्छी तरह से कंटेनरों और एल्गोरिदम के साथ जाने का फैसला कर सकते हैं, लेकिन स्ट्रिंग्स और i / o के लिए Std Lib के बाहर कुछ का उपयोग करने का निर्णय लेते हैं।

— मार्टिन बा
स्रोत

3

यह व्यावहारिक नहीं है, जब तक कि ऐसा करने का कोई भारी कारण न हो। ऐसे कुछ कारण, जिनके बारे में मैं केवल आंशिक या एसटीएल (या मानक पुस्तकालय का कोई अन्य हिस्सा) के कार्यान्वयन में कमी या संसाधन सीमा (मेमोरी, सीपीयू की गति, भंडारण, ...) शामिल कर सकता हूं, जिसे आपको प्राप्त करना है अपने स्वयं के औजारों को रोल करना जो आपको पूरा करने की आवश्यकता का पालन करते हैं।

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

"हर सक्सेसफुल गेम आपके खुद के लिंक्ड लिस्ट इम्प्लीमेंटेशन को रोल आउट करके शुरू होता है।"

— zxcdw
स्रोत

1

मुझे लगता है कि मानक पुस्तकालय का उपयोग करके कोड लिखने से हर सफल खेल शुरू होता है और फिर खेल को बड़े पैमाने पर प्रोफाइल किए जाने के बाद केवल कोड का अनुकूलन होता है। अनुकूलन करने से पहले डेटा का अनुकूलन करना यह बताता है कि अनुकूलन की आवश्यकता क्या है।

— Cromulent

सच। अंतिम वाक्यांश 90 के दशक के शुरुआती दिनों में गेम लिखने के "प्राचीन" तरीके पर एक नाटक था, जब सी ++ यह व्यापक रूप से तैनात नहीं था और विधानसभा + सी जाने का रास्ता था। शायद मुझे इसे और स्पष्ट करना चाहिए था। यह कंसोल में खेल उद्योग के लिए अच्छी तरह से लागू होता है, हालांकि, अधिकांश अल्गॉर्थ और डेटा संरचनाएं डिफ़ॉल्ट रूप से हाथ से लिखी जाती हैं क्योंकि प्रत्येक बाइट और चक्र मायने रखता है (हाँ, यहां तक कि रखरखाव / पोर्टेबिलिटी / जो भी हो) की कीमत पर।

— zxcdw

2

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

— Jan Hudec

2

@JanHudec बात यह है कि कार्य के लिए कार्यान्वयन (और व्यवहार भी, जलसेक) बहुत अनुरूप होना चाहिए। आप बस कुछ दर्जन बाइट्स को यहां और वहां (संदर्भ के इलाके को बर्बाद करते हुए) नहीं छोड़ सकते, इनपुट को सत्यापित करने के लिए कुछ शाखाओं में छोड़ दें (शाखा गलतफहमी और अनुदेश कैश याद आती है) और मान लें कि कंपाइलर अपने डेटा-संरचनाओं को वेक्टर करना जानता है। SIMD का लाभ उठाने के लिए (यह नहीं होगा, या कम से कम आपको यह सत्यापित करना होगा कि यह क्या सही है)। बेशक एक पीसी पर वास्तविक समय सॉफ्टवेयर लिखना उतना सख्त नहीं है, आप हमेशा तेज सीपीयू में फेंक सकते हैं। शान्ति में नहीं।

— zxcdw