सी ++ एसटीएल, 1995 के निर्माता के साथ साक्षात्कार। भाग 3

इंटरव्यू के अनुवाद का अंतिम भाग ( पहला भाग , दूसरा भाग ), 1995 में स्टैंडर्ड टेम्पलेट लाइब्रेरी एलेक्स स्टेपानोव के निर्माता से लिया गया था। यहां एलेक्स इस बारे में बात करता है कि दृढ़ता और क्रमबद्धता के लिए समर्थन टेम्पलेट्स में शामिल नहीं हैं, पुस्तकालय के भविष्य के बारे में और ओओपी और सामान्यीकृत प्रोग्रामिंग के बीच संबंध के बारे में।

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

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

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

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

क्या कंपाइलर डेवलपर्स आपके उत्पादों में एसटीएल लागू करने के लिए आपके साथ काम करते हैं?

हां। मुझे कंपाइलर प्रोवाइडर्स से बहुत सारे कॉल आते हैं। बोरलैंड के पीट बेकर बेहद मददगार थे। इसने कोड लिखकर मदद की, ताकि हम बोरलैंड संकलक के सभी मेमोरी मॉडल के लिए एलोकेटर को लागू करने में सक्षम हो। Symantec उनके Macintosh संकलक के लिए एक STL कार्यान्वयन जारी करने वाला है। एडिसन डिजाइन ग्रुप बहुत मददगार था। हमें अधिकांश संकलक प्रदाताओं से अच्छा समर्थन मिला।

STL में 16-बिट MS-DOS कंपाइलर्स के मेमोरी मॉडल को सपोर्ट करने वाले टेम्प्लेट शामिल हैं। 32-बिट आर्किटेक्चर, संकलक और ऑपरेटिंग सिस्टम के एक फ्लैट मॉडल पर वर्तमान फोकस के साथ, क्या आपको लगता है कि मेमोरी मॉडल का वर्तमान पूर्वाग्रह सच रहेगा?

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

ANSI / ISO C मानकों ने प्लेटफ़ॉर्म-विशिष्ट मुद्दों जैसे मेमोरी मॉडल, कार्यान्वयन विवरण की जांच की और उन्हें व्यवस्थित करने का प्रयास नहीं किया। क्या C ++ समिति इन मुद्दों पर एक अलग दृष्टिकोण लेगी? यदि हां, तो क्यों?

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

C ++ मानक लाइब्रेरी उपसमिति मानक नामस्थान और अपवाद हैंडलिंग सम्मेलनों को परिभाषित करती है। क्या एसटीएल कक्षाओं में नाम स्थान और अपवाद होंगे?

हाँ, वे करेंगे। समिति के सदस्य इसके साथ काम करते हैं और एक उत्कृष्ट काम करते हैं।

एसटीएल की वर्तमान परिभाषा से संभावित मानक कितना भिन्न होगा? क्या कमेटी अधिक नियंत्रण से बदलाव या डिजाइन से प्रभावित होगी?

ऐसा प्रतीत होता है कि आम सहमति एसटीएल में महत्वपूर्ण परिवर्तन नहीं होनी चाहिए।

इसके मानकीकरण की प्रत्याशा में प्रोग्रामर एसटीएल के साथ अपना पहला अनुभव कैसे प्राप्त कर सकते हैं?

वे एसटीएल बटलर .hpl.hp.com हेडर फ़ाइलों को / एसटीएल में डाउनलोड कर सकते हैं और इसका उपयोग बोरलैंड या आईबीएम कंपाइलर के साथ, या एसटीएल से निपटने के लिए पर्याप्त शक्तिशाली किसी अन्य कंपाइलर के साथ कर सकते हैं। किसी विशेष प्रोग्रामिंग शैली को सीखने का एकमात्र तरीका उस शैली में सीधे प्रोग्राम करना है। उन्हें उदाहरणों को देखना चाहिए और इस शैली में कार्यक्रम लिखना चाहिए।

आप STL के बारे में एक पुस्तक लिखने के लिए PJ (बिल) प्लग इन के साथ सहयोग कर रहे हैं। पुस्तक का मुख्य विचार क्या होगा, और इसे प्रकाशन के लिए कब नियोजित किया जाएगा?

यह 1995 की गर्मियों के लिए योजनाबद्ध है और एक एनोटेट एसटीएल कार्यान्वयन बन जाएगा। यह सी मानक पर बिल की पुस्तकों और सी ++ लाइब्रेरी मानक के मसौदे की तरह होगा। वह पुस्तक का संरक्षण करता है, इसलिए पुस्तक एसटीएल के मानक और उपयोग के संदर्भ के रूप में काम करेगी। मुझे बजरन के साथ एक लेख लिखने की उम्मीद है जो सी ++ और एसटीएल के संदर्भ में भाषा और पुस्तकालय की बातचीत पर चर्चा करेगा। और इससे एक और किताब हो सकती है।

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

सामान्यीकृत और वस्तु-उन्मुख प्रोग्रामिंग के बीच क्या संबंध है?

एक अर्थ में, सामान्यीकृत प्रोग्रामिंग ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के मूल विचारों का एक स्वाभाविक विस्तार है - इंटरफ़ेस और कार्यान्वयन की जुदाई और घटकों के बहुरूपी व्यवहार। हालांकि, एक बुनियादी अंतर है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग कार्यक्रमों के डिजाइन में भाषा तत्वों के सिंटैक्स पर जोर देती है। आपको वंशानुक्रम का उपयोग करना चाहिए, आपको कक्षाओं का उपयोग करना होगा, आपको वस्तुओं का उपयोग करना होगा, वस्तुओं को संदेश भेजना चाहिए। जेनेरिक प्रोग्रामिंग यह निर्धारित करने से शुरू नहीं होती है कि आप विरासत का उपयोग करते हैं या नहीं। यह वर्गीकरण को पहचानने या उत्पन्न करने के प्रयास से शुरू होता है कि उनमें क्या वस्तुएं हैं और वे कैसे व्यवहार करते हैं। यही है, इसका क्या मतलब है - दो चीजें समान हैं? पहचान निर्धारित करने के लिए कौन सा तरीका सही है? मुद्दा केवल यही नहीं है कि समान वस्तुओं का व्यवहार क्या है। आप पहचान का अधिक गहराई से विश्लेषण कर सकते हैं और पा सकते हैं कि समानता की एक सामान्य अवधारणा है जिसमें दो वस्तुएं समान हैं यदि उनके भाग, या कम से कम उनके मुख्य भाग समान हैं। हम एक समानता ऑपरेशन के लिए एक सामान्य नुस्खा प्राप्त कर सकते हैं। हम चर्चा कर सकते हैं कि किस प्रकार की वस्तुएं हैं। क्रम हैं। अनुक्रमों पर संचालन होते हैं। इन ऑपरेशनों का शब्दार्थ क्या है? जटिलता के दृष्टिकोण से किस प्रकार के अनुक्रम हमें उपयोगकर्ता को पेश करने चाहिए? अनुक्रमों के लिए एल्गोरिदम क्या हैं? हमें अलग-अलग छंटनी वाले कार्यों की क्या आवश्यकता है? और इसके बाद ही हम इसे निर्धारित करते हैं और घटकों की वैचारिक टैक्सोनॉमी प्राप्त करते हैं, हम तय करते हैं कि उन्हें कैसे लागू किया जाए। क्या हम टेम्पलेट का उपयोग करेंगे? क्या हम विरासत का उपयोग करते हैं? क्या हम मैक्रोज़ का उपयोग करते हैं? हम किस भाषा तकनीक का उपयोग करते हैं? सामान्यीकृत प्रोग्रामिंग का मुख्य विचार अमूर्त सॉफ्टवेयर घटकों और उनके व्यवहार को वर्गीकृत करना और एक मानक वर्गीकरण बनाना है। प्रारंभिक बिंदु वास्तविक, कुशल एल्गोरिदम और डेटा संरचनाएं हैं, न कि भाषा। बेशक, यह हमेशा एक विशेष भाषा में सन्निहित है। आप भाषा के बाहर सामान्यीकृत प्रोग्रामिंग नहीं कर सकते। STL C ++ में लिखा गया है। आप इसे Ada पर लागू कर सकते हैं। आप इसे अन्य भाषाओं में लागू कर सकते हैं। वे थोड़े अलग होंगे, लेकिन कुछ मूलभूत चीजें हैं जो वहां होंगी। बाइनरी खोज हर जगह होनी चाहिए। हर जगह छँटाई होनी चाहिए। ऐसा आमतौर पर लोग करते हैं। कंटेनरों के शब्दार्थ में कुछ बदलाव होंगे, भाषा द्वारा परिभाषित छोटे बदलाव। कुछ भाषाओं में आप विरासत का अधिक से अधिक उपयोग कर सकते हैं, कुछ भाषाओं में आपको टेम्प्लेट का उपयोग करना चाहिए। लेकिन मूल अंतर यह है कि सामान्यीकृत प्रोग्रामिंग अर्थ-विज्ञान और अर्थ-विघटन के साथ ठीक शुरू होती है। उदाहरण के लिए, हम तय करते हैं कि हमें स्वैप नामक एक घटक की आवश्यकता है। तब हमें पता चलता है कि यह घटक विभिन्न भाषाओं में कैसे काम करेगा। जोर शब्दार्थ और अर्थ वर्गीकरण पर है, जबकि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में, खासकर अगर आपको याद है कि यह कैसे विकसित हुआ, बहुत अधिक ध्यान, और, मुझे लगता है, बहुत अधिक ध्यान, चीजों को बनाने के लिए बिल्कुल भुगतान किया जाता है, अर्थात्। वर्ग पदानुक्रम का उपयोग करना। OOP आपको बताता है कि वर्ग पदानुक्रम कैसे बनाएं, लेकिन यह नहीं बताता कि इन श्रेणी पदानुक्रमों के अंदर क्या होना चाहिए।

आप एसटीएल और सामान्यीकृत प्रोग्रामिंग के भविष्य की कल्पना कैसे करते हैं?

मैंने पहले ही कहा है कि प्रोग्रामर का सपना उन अमूर्त घटकों के मानक रिपोजिटरी हैं, जो कि अच्छी तरह से समझे जाने वाले और सामान्य प्रतिमानों का पालन करने वाले इंटरफेस के घटक हैं। इसे पूरा करने के लिए, इस प्रोग्रामिंग शैली की वैज्ञानिक नींव को विकसित करने के लिए बहुत अधिक प्रयास होना चाहिए। एसटीएल ने कुछ बुनियादी घटकों के शब्दार्थों को वर्गीकृत करते हुए इसे कुछ हद तक लॉन्च किया। हमें इस पर और काम करने की जरूरत है। लक्ष्य एक शिल्प अनुशासन से सॉफ्टवेयर विकास को इंजीनियरिंग अनुशासन में बदलना है। इसे बुनियादी अवधारणाओं और इन कानूनों को संचालित करने वाले कुछ कानूनों की जरूरत है, जिन्हें अच्छी तरह से समझा जाए, जिन्हें सिखाया जा सकता है, जिसे हर प्रोग्रामर जानता है, भले ही वह उन्हें सही तरीके से तैयार करने में सक्षम न हो। बहुत से लोग अंकगणित जानते हैं, भले ही उन्होंने कभी कम्यूटेटिविटी के बारे में नहीं सुना हो। हर कोई जो स्कूल से स्नातक है, वह जानता है कि 2 + 5 5 + 2 है। उन सभी को नहीं पता है कि यह कम्यूटेटिव एडिशन की संपत्ति है। मुझे आशा है कि अधिकांश प्रोग्रामर बुनियादी कार्यों के मौलिक अर्थ गुणों को जानते हैं। असाइनमेंट का क्या मतलब है? समानता का क्या अर्थ है? डेटा संरचनाओं को कैसे डिज़ाइन करें।
C ++ वर्तमान में इस प्रोग्रामिंग शैली का सबसे अच्छा साधन है। मैंने विभिन्न भाषाओं की कोशिश की है, और मुझे लगता है कि सी ++ सार और दक्षता का अद्भुत संयोजन प्रदान करता है। हालाँकि, मुझे लगता है कि सी और कई विचारों के आधार पर एक भाषा विकसित करना संभव है, जिसे सी ++ लाया गया था, लेकिन इस प्रोग्रामिंग शैली के लिए अधिक उपयुक्त भाषा है, जिसमें सी ++ की कुछ कमियों का अभाव है, खासकर इसके विशाल आकार का। STL अवधारणाओं से संबंधित है। क्या एक पुनरावृत्ति है? क्लास नहीं। प्रकार नहीं है। यह एक अवधारणा है। (या, यदि हम अधिक औपचारिक होना चाहते हैं, तो यह वही है जो बॉर्बकी ने संरचनात्मक प्रकार को कॉल किया, जिसे तर्कशास्त्री सिद्धांत कहते हैं, या प्रकार सिद्धांत के क्षेत्र में लोग किस प्रकार को कहते हैं)। यह कुछ ऐसा है जिसमें C ++ में भाषा का अवतार नहीं है। लेकिन यह हो सकता है। आपके पास एक भाषा हो सकती है जहाँ आप अवधारणाएँ तैयार कर सकते हैं, उन्हें स्पष्ट कर सकते हैं और अंत में उन्हें एक निश्चित तरीके से कक्षाओं में बदल सकते हैं। (निश्चित रूप से, ऐसी भाषाएँ हैं जो प्रजाति के साथ काम करती हैं, लेकिन यदि आप केवल छांटना चाहते हैं तो वे बहुत मायने नहीं रखते हैं।) हमारे पास एक भाषा हो सकती है जिसमें कुछ चीज़ों को परिभाषित किया जा सकता है, जिसे एक अग्रगामी कहा जाता है, जिसे अवधारणा के रूप में एसटीएल में परिभाषित किया जाता है - और C ++ कोई अवतार नहीं है। इसके बाद, हम अग्रगामी को एक द्विदिश पुनरावृत्‍ति में परिशोधित कर सकते हैं। फिर यादृच्छिक पुनरावृत्ति को द्विदिश से परिष्कृत किया जा सकता है। आप एक ऐसी भाषा विकसित कर सकते हैं जिससे इस शैली में कार्यक्रम करना और भी आसान हो जाए। मैं पूरी तरह से आश्वस्त हूं कि यह कुशल और मशीन के करीब होना चाहिए जैसे कि सी और सी ++। और मेरा मानना ​​है कि आप एक ऐसी भाषा का निर्माण कर सकते हैं जो आपको एक ओर मशीन के करीब पहुंचने की अनुमति देती है, और दूसरी ओर बहुत ही अमूर्त वस्तुओं से निपटने में सक्षम है। मुझे लगता है कि अंतर्निहित मशीनों के बीच अंतर के बिना सी ++ की तुलना में और भी अधिक सार हो सकता है। मुझे लगता है कि सामान्य प्रोग्रामिंग भाषा अनुसंधान को प्रभावित कर सकती है, और हमारे पास व्यावहारिक भाषाएं होंगी जो इस प्रोग्रामिंग शैली के लिए उपयोग करने में आसान और अच्छी तरह से अनुकूल हैं। इससे, आप समझ सकते हैं कि मैं किस योजना पर काम कर रहा हूं।