एसटीएल या एसटीएल के लिए, यह सवाल

Question

निर्विवाद रूप से, मैं अधिकांश सी ++ प्रोग्रामिंग परियोजनाओं के लिए एसटीएल का उपयोग करना चुनूंगा। सवाल हाल ही में मुझे प्रस्तुत किया गया था, "क्या कोई ऐसे मामले हैं जहां आप एसटीएल का उपयोग नहीं करेंगे?" ...

जितना मैंने सोचा, उतना ही मुझे एहसास हुआ कि शायद ऐसे मामले हो सकते हैं जहां मैं एसटीएल का उपयोग न करने का चयन करें ... उदाहरण के लिए, वास्तव में एक बड़ी, लंबी अवधि की परियोजना जिसका कोडबेस पिछले वर्षों से होने की उम्मीद है ... शायद एक कस्टम कंटेनर समाधान जो परियोजनाओं की आवश्यकताओं के अनुरूप है, प्रारंभिक ओवरहेड के लायक है? आपको क्या लगता है, क्या ऐसे कोई मामले हैं जहां आप एसटीएल नहीं चुनेंगे?

Answer 1

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

आप किसी विशेष मामले के लिए एसटीएल का उपयोग न करने का भी चयन कर सकते हैं क्योंकि अधिक लागू कंटेनर मौजूद हैं जो मौजूदा मानक में नहीं हैं, जैसे boost :: array या boost :: unordered_map।

Answer 2

आमतौर पर, मुझे लगता है कि एसटीएल का उपयोग एसटीएल कंटेनरों को हाथ से लुढ़काए रखने के बजाय कस्टम आवंटकों के साथ करना है। एसटीएल के बारे में अच्छी बात यह है कि आप केवल वही भुगतान करते हैं जो आप उपयोग करते हैं।

Answer 3

मुझे लगता है कि यह एक ठेठ निर्माण बनाम खरीद परिदृश्य है। हालांकि, मुझे लगता है कि इस मामले में मैं लगभग हमेशा 'खरीद' करता हूं, और स्वयं को रोल करने से पहले एसटीएल - या बेहतर समाधान (बूस्ट से कुछ) का उपयोग करता हूं। आपको अपने आवेदन के बारे में अपने अधिकांश प्रयासों पर ध्यान केंद्रित करना चाहिए, न कि बिल्डिंग ब्लॉक का उपयोग करता है।

Answer 4

मुख्य कारणों एसटीएल उपयोग करने के लिए नहीं कर रहे हैं कि:

1. आपका सी ++ कार्यान्वयन पुराना है और भयानक टेम्पलेट समर्थन हासिल है।
2. आप गतिशील स्मृति आवंटन का उपयोग नहीं कर सकते हैं।

दोनों अभ्यास में बहुत असामान्य आवश्यकताएं हैं।

एक लंबे समय तक परियोजना के लिए अपने स्वयं के कंटेनर रोलिंग के लिए जो एसटीएल के साथ कार्यक्षमता में ओवरलैप है, सिर्फ रखरखाव और विकास लागत में वृद्धि करने जा रहा है।

Answer 5

मुझे वास्तव में ऐसा नहीं लगता है। अपने स्वयं के कंटेनर बनाने में, मैं उन एसटीएल के साथ संगत बनाने की भी कोशिश करता हूं क्योंकि जेनेरिक एल्गोरिदम की शक्ति छोड़ने के लिए बहुत बढ़िया है। एसटीएल कम से कम नाममात्र रूप से इस्तेमाल किया जाना चाहिए, भले ही आप जो भी करते हैं वह अपना कंटेनर लिखें और इसके लिए प्रत्येक एल्गोरिदम विशेषज्ञ करें। इस तरह, प्रत्येक सॉर्टिंग एल्गोरिदम को सॉर्ट किया जा सकता है (c.begin(), c.end())। यदि आप समान प्रभाव रखने के लिए सॉर्ट करें, भले ही यह अलग-अलग काम करता हो।

Answer 6

मुझे बहु थ्रेडेड कोड में एसटीएल का उपयोग करने में समस्याएं मिली हैं। भले ही आप थ्रेड में एसटीएल ऑब्जेक्ट्स साझा नहीं करते हैं, फिर भी कई कार्यान्वयन गैर-थ्रेड सुरक्षित संरचनाओं का उपयोग करते हैं (जैसे इंटरलॉक किए गए वृद्धि शैली के बजाय संदर्भ गिनती के लिए ++, या गैर थ्रेड-सुरक्षित आवंटक)।

इन मामलों में से प्रत्येक में, मैंने अभी भी एसटीएल का उपयोग करने और समस्याओं को ठीक करने का विकल्प चुना है (आप जो चाहते हैं उसे प्राप्त करने के लिए पर्याप्त हुक हैं)।

भले ही आप अपने स्वयं के संग्रह करने का विकल्प चुनते हैं, फिर भी यह इटरेटर्स के लिए एसटीएल शैली का पालन करना एक अच्छा विचार होगा ताकि आप एल्गोरिदम और अन्य एसटीएल कार्यों का उपयोग कर सकें जो केवल इटरेटर पर ही काम करते हैं।

Answer 7

एसएलएल का उपयोग करने के लिए बहुत सारे फायदे हैं। दीर्घकालिक परियोजना के लिए लाभ लागत से अधिक है।

1. नए प्रोग्रामर प्रोजेक्ट में अन्य कोड सीखने के लिए उन्हें अधिक समय देने वाले दिन से कंटेनरों को समझने में सक्षम होते हैं। (मानते हैं कि वे पहले से ही किसी भी सक्षम सी ++ प्रोग्रामर की तरह एसटीएल जानते हैं)
2. कंटेनरों में फिक्सिंग बग बेकार और समय बर्बाद कर देता है जिसे व्यापार तर्क को बढ़ाने में खर्च किया जा सकता है।
3. अधिकतर संभावना है कि आप उन्हें लिखने के साथ-साथ एसटीएल को भी लागू नहीं किया जा रहा है।

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

Answer 8

मैंने जिन परियोजनाओं पर काम किया है, उनमें से अधिकांश एसटीएल के वास्तव में उपयोग करने योग्य संस्करण की तुलना में कोडबेस तरीका पुराना था - इसलिए हमने इसे अभी पेश नहीं करना चुना।

Answer 9

मैंने जो मुख्य मुद्दा देखा है वह विरासत कोड के साथ एकीकृत होना है जो गैर-फेंकने वाले ऑपरेटर पर निर्भर करता है।

Answer 10

मैंने 1 9 84 में या तो सी प्रोग्रामिंग शुरू कर दी और कभी भी एसटीएल का उपयोग नहीं किया। सालों से मैंने अपनी खुद की फ़ंक्शन लाइब्रेरी लॉन्च की है और एसटीएल स्थिर नहीं होने पर और क्रॉस प्लेटफ़ॉर्म समर्थन की कमी होने पर वे विकसित और उगाए गए हैं। मेरी आम पुस्तकालय में दूसरों द्वारा कोड शामिल किया गया है (ज्यादातर चीजें जैसे libjpeg, libpng, ffmpeg, mysql) और कुछ अन्य और मैं इसके बजाय बाहरी कोड की मात्रा को कम से कम रखूंगा। मुझे यकीन है कि अब एसटीएल बहुत अच्छा है लेकिन स्पष्ट रूप से मैं अपने टूलबॉक्स में वस्तुओं से खुश हूं और इस बिंदु पर इसे और अधिक टूल के साथ लोड करने की आवश्यकता नहीं है। लेकिन मैं निश्चित रूप से महान छलांग और सीमाओं को देखता हूं जो नए प्रोग्रामर एसटीएल का उपयोग करके स्क्रैच से कोड को कोड किए बिना कर सकते हैं।

Answer 11

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

Answer 12

सिम्बियन के लिए कोडिंग।

एसटीएलपोर्ट, सिम्बियन 9 का समर्थन करता है, इसलिए एसटीएल का उपयोग करने के मामले में यह कमजोर है ("यह उपलब्ध नहीं है" एक बहुत ही भरोसेमंद मामला है, लेकिन एसटीएल अभी भी सभी सिम्बियन पुस्तकालयों के लिए विदेशी है, इसलिए हो सकता है केवल सिम्बियन तरीके से काम करने से ज्यादा परेशानी।

बेशक यह इन आधारों पर तर्क दिया जा सकता है कि सिम्बियन के लिए कोडिंग "सी ++ प्रोग्रामिंग प्रोजेक्ट" नहीं है।

Answer 13

मानक सी ++ कुछ iterator operations to throw exceptions के कार्यान्वयन की अनुमति देता है। कुछ मामलों में यह संभावना समस्याग्रस्त हो सकती है। इसलिए आप अपने स्वयं के साधारण कंटेनर को कार्यान्वित कर सकते हैं जो कि महत्वपूर्ण संचालन के लिए अपवाद फेंकने की गारंटी नहीं देता है।

Answer 14

परिचय:

एसटीएल एक महान पुस्तकालय, और कई मामलों में उपयोगी है, लेकिन यह निश्चित सभी स्थितियों का समाधान नहीं है। उत्तर एसटीएल या!एसटीएल जवाब देने जैसा है "क्या एसटीएल आपकी ज़रूरत को पूरा करता है या नहीं?" एसटीएल

• अधिकांश स्थितियों में की

  पेशेवरों, एसटीएल एक कंटेनर है कि किसी भी समाधान के लिए फिट है।

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

एसटीएल

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

निम्नलिखित पहलू केवल कुछ उदाहरण हैं, लेकिन मूल रूप से वे इस तथ्य का परिणाम हैं: एसटीएल सीमा के साथ वास्तविक पुस्तकालय है।

• अपवाद: अपवाद पर एसटीएल रिले, इसलिए यदि किसी भी कारण से आप अपवाद स्वीकार नहीं कर सकते हैं (उदा सुरक्षा महत्वपूर्ण), तो आपको एसटीएल उपयोग नहीं कर सकते। सही! अपवाद अक्षम हो सकते हैं, लेकिन यह उन पर एसटीएल रिलेइंग के डिजाइन को हल नहीं करता है और अंततः एक दुर्घटनाग्रस्त हो जाएगा। विशिष्ट की

• आवश्यकता (अभी तक शामिल नहीं) डेटा संरचना: ग्राफ, पेड़, आदि

• जटिलता के विशेष की कमी: आप कि एसटीएल सामान्य प्रयोजन कंटेनर खोज सकता है आपके टोंटी कोड के लिए सबसे इष्टतम नहीं है।

• कन्करेंसी विचार: या तो आप संगामिति और एसटीएल जरूरत है प्रदान नहीं करते हैं कि तुम क्या जरूरत है (उदाहरण के लिए पाठक लेखक ताला (आसानी से) द्वि-दिशात्मक [] operator की वजह से नहीं किया जा सकता)। या तो आप एक कंटेनर को बहुत तेजी से पहुंच/खोज/डालने/जो भी हो, के लिए बहु-थ्रेडिंग का लाभ ले सकते हैं।

• एसटीएल को आपकी जरूरतों को पूरा करने की आवश्यकता है, लेकिन रिवर्स भी सच है: आपको एसटीएल की जरूरतों को पूरा करने की आवश्यकता है। std::vector का उपयोग एम्बेडेड माइक्रो-कंट्रोलर में 1K अप्रबंधित रैम के साथ करने का प्रयास न करें।

• अन्य पुस्तकालयों के साथ संगतता: यह हो सकता है कि ऐतिहासिक कारणों से, आपके द्वारा उपयोग की जाने वाली लाइब्रेरी एसटीएल स्वीकार नहीं करते हैं (उदा। QtWidgets अपने स्वयं के QList का गहन उपयोग करते हैं)। दोनों दिशाओं में कंटेनर कनवर्ट करना सबसे अच्छा समाधान नहीं हो सकता है।

---

अपने स्वयं के कंटेनर

को लागू करने कि पढ़ने के बाद, आपको लगता है सकते हैं: "ठीक है, मैं मैं एसटीएल की तुलना में मेरी विशेष मामले के लिए कुछ बेहतर कर सकते हैं यकीन करता।" रुकिए!

अपने कंटेनर सही ढंग से बहुत एक बड़ा काम जल्दी से बन लागू करना: यह न केवल कुछ काम कर लागू करने के बारे, आप के लिए हो सकता है है:

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

कोड का इस्तेमाल किया है कि एक कंटेनर की तरह कोड में गहरी निश्चित कुछ है कि समय लेने के लिए लागू करने के लिए, और हालांकि सावधानी से किया जाना चाहिए है।

---

3 पार्टी पुस्तकालय

नहीं एसटीएल का उपयोग करना जरूरी कस्टम मतलब यह नहीं है। नेट में बहुत अच्छी पुस्तकालय हैं, कुछ अनुमोदित ओपन-सोर्स लाइसेंस के साथ भी।

कोई अतिरिक्त तृतीय पक्ष लाइब्रेरी जोड़ना या नहीं, एक और विषय है, लेकिन यह माना जा सकता है।