2009-09-22 6 views
28

उदाहरण के लिए एसटीएल कार्यान्वयन में अधिकांश सदस्यों को _M_ या _ या __ उपसर्ग क्यों है? इतना बॉयलरप्लेट कोड क्यों है?एसटीएल कार्यान्वयन इतना अपठनीय क्यों है? सी ++ कैसे सुधार किया जा सकता था?

सी ++ की क्या विशेषताएं हैं जो वेक्टर (उदाहरण के लिए) कार्यान्वयन को स्पष्ट और अधिक संक्षिप्त बनाने की अनुमति देगी?

+0

एसटीएल का कौन सा कार्यान्वयन आप जिक्र कर रहे हैं? – morechilli

+7

और आप कार्यान्वयन के विवरण की परवाह क्यों करते हैं? –

+2

कुछ एसटीएल कार्यान्वयन जानबूझकर terse लिखा जाता है। जिस तरह से कोड लिखा गया है वह मानक के दायरे से कुछ अच्छी तरह से बाहर है - तथ्य यह है कि आपका कार्यान्वयन मानक अनुपालन है, अधिकांश परिस्थितियों में आपको वह सारी जानकारी चाहिए जो आपको चाहिए। –

उत्तर

34

कार्यान्वयन उपयोगकर्ता द्वारा परिभाषित मैक्रोज़ के साथ संघर्ष से बचने के लिए अंडरस्कोर से शुरू होने वाले नामों का उपयोग करते हैं, इसके बाद अपरकेस अक्षर या दो अंडरस्कोर होते हैं। ऐसे नाम सी ++ में आरक्षित हैं। उदाहरण के लिए, कोई Type नामक मैक्रो को परिभाषित कर सकता है और फिर #include <vector>। यदि vector कार्यान्वयन Type टेम्पलेट पैरामीटर नाम के रूप में उपयोग किया जाता है, तो यह टूट जाएगा। हालांकि, _Type (या __type, type__ आदि नामक मैक्रोज़ को परिभाषित करने की अनुमति नहीं है)। इसलिए, vector सुरक्षित रूप से ऐसे नामों का उपयोग कर सकते हैं।

+0

+1। जीसीसी के कार्यान्वयन में एक टिप्पणी भी शामिल है जिसमें कतार के अंतर्निहित कंटेनर को सी कहा जाता है और "स्टाइल दिशानिर्देशों के अनुसार उलझन में नहीं" कहा जाता है। – UncleBens

+2

तो मैक्रोज़ सिस्टम को अधिक शक्तिशाली बनाकर सी ++ में सुधार किया जा सकता था :) –

+2

मैक्रोज़ के लिए नेमस्पेस? – Aardvark

5

बहुत सारे एसटीएल कार्यान्वयन में डीबग बिल्डों की जांच भी शामिल है, जैसे कि यह सत्यापित करते हुए कि दो पुनरावर्तक एक ही कंटेनर से हैं, जबकि उनकी तुलना करते समय, और सीमाओं से बाहर जाने वाले इटरेटर के लिए देख रहे हैं। इसमें निर्मित प्रत्येक इटरेटर की कंटेनर और वैधता को ट्रैक करने के लिए काफी जटिल कोड शामिल है, लेकिन बग खोजने के लिए अमूल्य है। यह कोड भी मानक रिलीज कोड के साथ #ifdefs के साथ जुड़ा हुआ है - यहां तक ​​कि एसटीएल एल्गोरिदम में भी। तो यह कभी भी उनके सबसे बुनियादी ऑपरेशन के रूप में स्पष्ट नहीं होगा। this one जैसी साइटें एसटीएल एल्गोरिदम की सबसे बुनियादी कार्यक्षमता दिखाती हैं, जो बताती हैं कि उनकी कार्यक्षमता उनके द्वारा दिखाए गए कोड के बराबर है। हालांकि आप अपने हेडर फाइलों में नहीं देख पाएंगे।

2

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

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

संबंधित मुद्दे