🅱️ 🐱 👩🏼‍🎨 डी में स्वामित्व और उधार 🧘🏿 🕴️ 🚏

लगभग सभी गैर-तुच्छ कार्यक्रम गतिशील मेमोरी को आवंटित और उपयोग करते हैं। इसे सही ढंग से करना तेजी से महत्वपूर्ण होता जा रहा है क्योंकि कार्यक्रम अधिक जटिल हो जाते हैं और त्रुटियां और भी महंगी हो जाती हैं।

विशिष्ट समस्याएं हैं:

मेमोरी लीक (इस्तेमाल की गई मेमोरी को खाली नहीं करना)
डबल रिलीज़ (मेमोरी रिलीज़ एक से अधिक बार)
रिलीज के बाद उपयोग (पहले से मुक्त की गई मेमोरी के लिए पॉइंटर का उपयोग)

कार्य मेमोरी को मुक्त करने के लिए जिम्मेदार बिंदुओं को ट्रैक करना है (यानी, जो स्मृति के स्वामी हैं), और ऐसे बिंदुओं को भेद करने के लिए जो बस स्मृति के एक टुकड़े को इंगित करते हैं, नियंत्रण जहां वे स्थित हैं, और उनमें से कौन सक्रिय (दायरे में) है।

विशिष्ट समाधान इस प्रकार हैं:

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

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

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

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

अधिकार

स्मृति में वस्तु का मालिक होने का निर्णय हास्यास्पद रूप से सरल है - वस्तु के लिए एक एकल सूचक है और यह मालिक है। वह स्मृति की रिहाई के लिए भी जिम्मेदार है, जिसके बाद यह अमान्य हो जाता है। इस तथ्य के कारण कि स्मृति में ऑब्जेक्ट का सूचक मालिक है, इस डेटा संरचना के अंदर कोई अन्य संकेत नहीं हैं, और इसलिए डेटा संरचना एक पेड़ बनाती है।

दूसरा परिणाम यह है कि पॉइंटर्स नकल करने के बजाय बढ़ने के शब्दार्थ का उपयोग करते हैं:

T* f(); void g(T*); T* p = f(); T* q = p; //  p   q,    g(p); // , p

डेटा संरचना के अंदर से एक पॉइंटर को निकालना निषिद्ध है:

 struct S { T* p; } S* f(); S* s = f(); T* q = sp; // ,      sp

क्यों नहीं बस के रूप में अवैध निशान? समस्या यह है कि इसे रनटाइम में लेबल सेट करने की आवश्यकता होगी, लेकिन इसे संकलन चरण में हल किया जाना चाहिए, क्योंकि इसे बस एक संकलन त्रुटि माना जाता है।

स्वयं पॉइंटर से बाहर निकलने की गुंजाइश भी एक त्रुटि है:

 void h() { T* p = f(); } // ,   p?

आपको पॉइंटर मान को अलग तरीके से स्थानांतरित करना होगा:

 void g(T*); void h() { T* p = f(); g(p); //   g(),    g() }

यह मेमोरी लीक की समस्याओं और उपयोग को मुक्त करने के बाद हल करता है (संकेत: स्पष्टता के लिए, मल्लोक (), और जी) () के साथ मुक्त () के साथ च को बदलें।

यह सब डेटा फ्लो एनालिसिस (DFA) तकनीक का उपयोग करके संकलन चरण में सत्यापित किया जा सकता है, जैसे कि इसका उपयोग आम सबटेक्शंस को हटाने के लिए किया जाता है। DFA प्रोग्राम संक्रमण से उत्पन्न होने वाले किसी भी चूहे की उलझन को खोल सकता है।

उधार

ऊपर वर्णित कार्यकाल प्रणाली विश्वसनीय है, लेकिन बहुत अधिक प्रतिबंधात्मक है।
पर विचार करें:

 struct S { void car(); void bar(); } struct S* f(); S* s = f(); s.car(); // s   car() s.bar(); // , s

इस काम के लिए, s.car () के पास सूचक को निकास पर वापस लाने का एक तरीका होना चाहिए।

इस प्रकार उधार कार्य होता है। s.car () s.car () की अवधि के लिए s की एक प्रति लेता है। s रनटाइम पर अमान्य है, और s.car () से बाहर निकलने पर फिर से मान्य हो जाता है।

डी में, संरचना सदस्य कार्यों को संदर्भ द्वारा यह सूचक मिलता है, ताकि हम एक छोटे से विस्तार के साथ उधार को अनुकूलित कर सकें: संदर्भ द्वारा तर्क प्राप्त करना इसे लेता है।

डी भी संकेत की गुंजाइश का समर्थन करता है, इसलिए उधार स्वाभाविक है:

 void g(scope T*); T* f(); T* p = f(); g(p); // g()  p g(p); //    p     g()

(जब फ़ंक्शंस को संदर्भ या पॉइंटर्स द्वारा तर्क प्राप्त किया जाता है तो स्कोप का उपयोग किया जाता है, उन्हें किसी फ़ंक्शन या दायरे की सीमाओं से परे विस्तारित करने के लिए मना किया जाता है। यह उधार लेने के शब्दार्थ से मेल खाता है।)

इस तरह से उधार लेना किसी भी क्षण में मेमोरी में किसी ऑब्जेक्ट को सूचक की विशिष्टता की गारंटी देता है।

उधार को इस समझ के साथ आगे बढ़ाया जा सकता है कि स्वामित्व प्रणाली भी विश्वसनीय है, भले ही किसी वस्तु को कई स्थिर बिंदुओं द्वारा इंगित किया जाता है (लेकिन केवल एक ही परिवर्तनशील)। एक निरंतर पॉइंटर मेमोरी को बदल नहीं सकता है या उसे मुक्त नहीं कर सकता है। इसका मतलब है कि कई निरंतर पॉइंटर्स को उत्परिवर्तित स्वामी से उधार लिया जा सकता है, लेकिन उसे इन अधिकारों का उपयोग करने का कोई अधिकार नहीं है, जबकि ये निरंतर पॉइंटर्स जीवित हैं।

उदाहरण के लिए:

 T* f(); void g(T*); T* p = f(); // p   { scope const T* q = p; //    scope const T* r = p; //    g(p); // , p   q  r    } g(p); // ok

सिद्धांतों

पूर्वगामी निम्न समझ को कम किया जा सकता है कि स्मृति में कोई वस्तु ऐसा व्यवहार करती है जैसे कि वह दो में से एक अवस्था में हो:

वहाँ वास्तव में यह करने के लिए एक परस्पर सूचक है
एक या एक से अधिक अतिरिक्त निरंतर संकेत

एक चौकस पाठक ने जो कुछ लिखा है, उसमें कुछ अजीब लगेगा: "जैसे कि"। मैं क्या संकेत करना चाहता था? क्या चल रहा है? हां, एक है। कंप्यूटर प्रोग्रामिंग लैंग्वेज इस तरह से भरी हुई हैं जैसे "अगर" हुड के नीचे, आपके बैंक खाते में पैसे की तरह कुछ वास्तव में नहीं है (मैं माफी मांगता हूं कि यह किसी के लिए एक बड़ा झटका था), और यह इससे अलग नहीं है। पर पढ़ें!

लेकिन पहले, विषय में थोड़ा गहरा।

डी में स्वामित्व / उधार तकनीकों को एकीकृत करना

इन तकनीकों के साथ असंगत नहीं हैं जिस तरह से लोग आमतौर पर डी में लिखते हैं, और लगभग सभी मौजूदा डी प्रोग्राम नहीं तोड़ेंगे? और इसे ठीक करना इतना आसान नहीं है, लेकिन इतना है कि आपको स्क्रैच से सभी एल्गोरिदम को फिर से डिज़ाइन करना होगा?

हाँ वास्तव में। जब तक डी के पास एक (लगभग) गुप्त हथियार नहीं है: कार्यों की विशेषताएं। यह पता चला है कि स्वामित्व / उधार (ओबी) के शब्दार्थ को सामान्य शब्दार्थ विश्लेषण के बाद प्रत्येक फ़ंक्शन के लिए अलग से लागू किया जा सकता है। एक चौकस पाठक यह नोटिस कर सकता है कि कोई नया वाक्यविन्यास नहीं जोड़ा गया है, केवल मौजूदा कोड पर प्रतिबंध लगाए गए हैं। डी में पहले से ही अपने शब्दार्थ को बदलने के लिए फ़ंक्शन विशेषताओं का उपयोग करने का एक इतिहास है, उदाहरण के लिए, "शुद्ध" फ़ंक्शन बनाने के लिए शुद्ध विशेषता। OB शब्दार्थ को सक्षम करने के लिए, @ लाइव विशेषता जोड़ी जाती है।

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

मानो

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

लेकिन OB, RC के साथ कोड में ऑब्जेक्ट दिखता है जैसे कि यह सभी नियमों का पालन करता है, इसलिए कोई समस्या नहीं है!

यह ओबी के साथ सफलतापूर्वक काम करने के लिए कई समान पुस्तकालय प्रकारों को ले जाएगा।

निष्कर्ष

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

वाल्टर से आगे की चर्चा और टिप्पणियों के लिए, विषय / आर / प्रोग्रामिंग सबरेडिट और हैकर न्यूज़ पर विषयों को देखें।