सी ++ में जीसी: प्रलोभन पर काबू पाने

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

विधि का सार अत्यंत सरल है: यदि प्रत्येक वस्तु एक निश्चित दायरे का एक चर है या किसी अन्य वस्तु का एक साधारण ("स्टैक") सदस्य है, तब भी जब प्रोग्राम एक अखंड अपवाद से दुर्घटनाग्रस्त हो जाता है, तो सही सफाई हमेशा होगी। कार्य इस योजना के लिए विभिन्न प्रकार के गतिशील परिदृश्यों को कम करना है।

1. प्रत्येक वस्तु का ठीक एक मालिक होता है।

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

इस तरह से सभी वस्तुओं को रखकर, एक अखंड अपवाद को फेंकने के बाद भी, सही स्ट्रिपिंग का प्रदर्शन किया जाएगा।

class SomeParent { Child1 child1; Child2 child2; }; class Root { public: void Run(); private: SomeParent entry; }; int main(int argc, char **argv, char **envp) { Root().Run(); //   ,    } 

बेशक, यह सबसे स्पष्ट मामला है, इसमें कोई गतिशीलता शामिल नहीं है।
यह तब और दिलचस्प होता है जब निष्पादन के दौरान किसी वस्तु को बनाने की आवश्यकता होती है:

2. कंटेनर का मालिक।

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

 template <T> class One { public: One(); //  One(T *); //    void Clear(); //   T *operator->(); //   T *GetPtr(); ~One(); // }; //--- : class Owner { One<Entity> dynamicEntity; }; 

इस मामले में, हम कह सकते हैं कि कंटेनर ऑब्जेक्ट का मालिक है।

3. बकाया सरणियाँ।

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

 template <T> class Array { public: T & Add(); T & Add(const T &); // T & Add(T *); //   ~Array(); //   }; //   - : template <K,T> class ArrayMap { public: T & Add(const K &); T & Add(const K &, const T &); // T & Add(const K &, T *); //   ~ArrayMap(); //   }; //--- : class Owner { Array<String> stringsArray; ArrayMap<int,String> anotherStringsCollection; }; 

यह स्पष्ट है कि वस्तुओं के पूरे संग्रह का मालिक एक ऐसा सरणी है जो मालिक वर्ग का एक सामान्य, "स्टैक्ड" सदस्य है।
इस तरह के स्वामित्व वाली प्राथमिकताओं से, आप काफी जटिल मॉडल बना सकते हैं। कठिनाई का अगला स्तर मालिकों के बीच वस्तुओं का हस्तांतरण है:

4. वस्तुओं का स्थानांतरण स्वामित्व का स्थानांतरण।

प्रत्येक वस्तु का ठीक एक मालिक होता है। मालिक वस्तु को दूसरे मालिक को हस्तांतरित कर सकता है, लेकिन वह वस्तु तक पहुंच खो देता है।
आप सरणियों और कंटेनरों में आंतरिक पॉइंटर की विनाशकारी प्रतिलिपि जोड़कर वस्तु को स्वामित्व के साथ स्थानांतरित कर सकते हैं:

 template <T> class One { public: //... One(const One<T> &source); //ptr = source.ptr; source.ptr = NULL; void operator=(const One<T> &source); //ptr = source.ptr; source.ptr = NULL; bool IsEmpty(); //,     private: mutable T *ptr; }; //      

नतीजतन, यदि मालिक अपने सदस्य फ़ंक्शन से एक सरणी या कंटेनर लौटाता है, तो उसने वास्तव में चाइल्ड ऑब्जेक्ट्स के स्वामित्व को कॉलिंग ऑब्जेक्ट में स्थानांतरित कर दिया। कॉल करने वाला नया मालिक बन गया है। और ऑब्जेक्ट्स के पास मेमोरी लीक बनने का कोई मौका नहीं है, क्योंकि उन्हें किसी के द्वारा साफ किए जाने की गारंटी है।

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

 class CleverEntity { public: void UpdateUI(Window *window) // ,     , //        { //window->... //: delete window     //     } }; class WindowWorker { public: void UpdateUI() { entity.UpdateUI(window.GetPtr()); } private: CleverEntity entity; One<Window> window; }; 

वह सब है।
शायद "सिल्वर बुलेट" नहीं, लेकिन अधिकांश अनुप्रयोगों के लिए, यह काफी पर्याप्त है।
अधिक जटिल परिदृश्य, यदि वांछित हो, तो टिप्पणियों में बाहर किया जा सकता है।

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

पिछले लेखों में से एक में दृष्टिकोण के कुछ सैद्धांतिक पहलुओं का वर्णन किया गया था।