सी ++ कचरा कलेक्टर

हेलो, हेब्र! मैं लंबे समय से इस लेख की योजना बना रहा हूं। यह C ++ में सबसे सरल कॉपी करने वाले कचरा संग्राहक के बारे में होगा। इसमें काफी कुछ प्रतिबंध हैं (भाग में हस्तक्षेप नहीं होता है, अगर किसी गंभीर पुस्तकालय को लिखना चाहते हैं तो भाग को दरकिनार किया जा सकता है, लेकिन कुछ के लिए भाषा से कुछ अल्पविकसित समर्थन प्राप्त करना अच्छा होगा), लेकिन इसमें कोड 100 लाइनों से थोड़ा अधिक है। रुचि कृपया बिल्ली के नीचे। कम से कम OOP, संकेत के साथ सबसे सरल पैटर्न और डरावना जादू की रस्में हैं।

शुरू से शुरू करते हैं। एक कचरा कलेक्टर क्या है और इसके लिए क्या है?

गर्गाबे कलेक्टर (जीसी) संसाधनों को प्रबंधित करने का एक ऐसा तरीका है, आमतौर पर रैम को ढेर पर आवंटित किया जाता है। नीचे की रेखा सरल है - प्रोग्रामर कचरा कलेक्टर को उसके लिए स्मृति का एक टुकड़ा आवंटित करने के लिए कहता है, और वह पहले से ही निर्धारित करता है कि कब उसकी ज़रूरत नहीं होगी और उसे मुक्त किया जा सकता है। यह अधिकांश मेमोरी लीक समस्याओं को हल करता है, हालांकि यह वीरतापूर्ण रूप से अतिरंजित विभाजन त्रुटियों को असंभव बनाता है। क्या अफ़सोस है।

दो प्रकार के कचरा संग्राहक हैं - रूढ़िवादी और नकल।

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

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

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

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

हैडर को कई तरह से इस्तेमाल भी किया जा सकता है। मेरा सबसे आसान है जो बिल्कुल भी हो सकता है (कार्यान्वयन के लिए, लेकिन उपयोग नहीं)। सबसे पहले, प्रत्येक वस्तु जो कचरा कलेक्टर के माध्यम से बनाने की योजना है, इसकी परिभाषा की शुरुआत में यह संरचना होनी चाहिए:

enum { STRUCT_SZ = 0, REF_COUNT = 1 }; struct gcHeader { union { int gcData[2]; gcHeader* post_gcAddress; }; }; 

दूसरे, हेडर के तुरंत बाद, और कहीं नहीं, सभी बिंदुओं पर जाना चाहिए जो कचरा कलेक्टर पर भी लागू होता है। तदनुसार, उनकी संख्या gcData [REF_COUNT] में संग्रहीत की जाएगी। यह उन सीमाओं में से एक है जिसे मेरा कार्यान्वयन लागू करता है। GcData [STRUCT_SZ] बाइट में संरचना का आकार संग्रहीत करेगा। मैं बाद में सूचक के उद्देश्य को प्रकट करूंगा। जो सुविधाजनक है, संरचना का आकार सूचक के आकार के बराबर था (अब 2014, लोग!)।

महान, अब हम अपनी स्मृति के आसपास प्राप्त कर सकते हैं। सवाल यह है कि कहां पहुंचना है। स्मृति का एकमात्र क्षेत्र जो किसी भी क्षण हमारे लिए बिल्कुल सुलभ है, वह है स्टैक। समस्या संरचनाओं में पॉइंटर्स के साथ समान है - हमें पता नहीं है कि बाइट्स का एक गुच्छा एक जीसी ऑब्जेक्ट को क्या इंगित करता है। इसलिए, प्रत्येक ऐसे पॉइंटर का स्थान स्पष्ट रूप से लिखा जाना चाहिए।

 vector<gcHeader**> referencesStack; template <class T> class stackRef { public: T* ref; stackRef(){ ref = nullptr; referencesStack.push_back(reinterpret_cast<gcHeader**>(&ref)); } ~stackRef(){ referencesStack.pop_back(); } }; 

StackRef वर्ग बस कार्य करता है। आरंभ करने पर, यह लिंक स्टैक पर अपना पता जोड़ता है। विध्वंसक, तदनुसार, एक ही ढेर से एक अप्रासंगिक पते को हटा देता है। विध्वंसक के साथ कॉल और कंस्ट्रक्टरों का ढेर सिंक्रनाइज़ किया जाता है, ताकि विसंगतियां न हों।

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

सहायक संरचनाएं तैयार हैं। आप मेमोरी के आवंटन पर जा सकते हैं।

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

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

 const int CHUNK_SIZE = 4096; const int OVERDRAFT = 128; const int ACTUAL_SIZE = CHUNK_SIZE + OVERDRAFT; //      15  ,  -   . struct gcChunk { gcChunk* next; char data[ACTUAL_SIZE];//     . }; gcChunk* firstChunk; gcChunk* currentChunk; int chunkCount; int currentOffset; 

FirstChunk सूची की शुरुआत है, currentChunk मेमोरी का अंतिम निर्मित ब्लॉक है। urrentOffset - currentChunk के सापेक्ष एक मुफ्त मेमोरी सेगमेंट की शुरुआत।

 gcHeader* gcRawAlloc(int size, int refCount){ if (size > CHUNK_SIZE)//  proof of concept,      return nullptr; if (currentOffset + size > CHUNK_SIZE){ //     list<gcChunk>  STL,   ,       . ++chunkCount; currentChunk->next = new gcChunk(); currentChunk = currentChunk->next; currentChunk->next = nullptr; currentOffset = 0; } gcHeader* new_obj = reinterpret_cast<gcHeader*>(&(currentChunk->data[currentOffset])); new_obj->gcData[STRUCT_SZ] = size; new_obj->gcData[REF_COUNT] = (refCount << 1)| 1; currentOffset += size; if (currentOffset % 4)//  4 .  ,    , ..         . currentOffset += 4 - currentOffset % 4; return new_obj;//        ,       ,    —   . } 

पहले से ही अधिक स्पष्ट संकेत हैं। 12 वीं पंक्ति का विश्लेषण करते हैं।
इस समय, हमारे लिए यह सोचना अधिक सुविधाजनक नहीं है कि नई वस्तु किस प्रकार की है। हम यह सुनिश्चित करने के लिए जानते हैं कि उसके पास हमारा gcHeader है, और यह अभी के लिए पर्याप्त है।
एक नई वस्तु के लिए मेमोरी आवंटित करने के बाद, हमें इसके शीर्षक को इनिशियलाइज़ करना होगा। क्या रहस्यमय असाइनमेंट का मतलब हो सकता है

 temp->gcData[REF_COUNT] = (refCount << 1)| 1; 

?

ऐसा करने के लिए, हेडर की परिभाषा पर फिर से गौर करें।

 struct gcHeader { union { int gcData[2]; gcHeader* post_gcAddress; }; }; 

यूनियन कीवर्ड का अर्थ है कि gcData सरणी और post_gcAddress पॉइंटर दोनों एक ही पते पर स्थित हैं। यह स्मृति को बचाने के लिए उपयोगी है, लेकिन समस्या यह है कि C ++ को याद नहीं है कि संघ में डेटा का उपयोग पिछली बार कैसे किया गया था - एक सरणी के रूप में, या एक संदर्भ के रूप में। प्रोसेसर आर्किटेक्चर की एक विशेषता, जैसे डेटा संरेखण की आवश्यकता, मदद करती है।

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

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

खैर, फ़ंक्शन पर एक छोटा आवरण, ताकि आवंटनक का उपयोग करने से बहुत दर्द न हो।

 template <class T> T* gcAlloc(){ return reinterpret_cast<T*>(gcRawAlloc(sizeof(T), T::refCount)); } 

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

इस फ़ंक्शन का उपयोग करने से पहले, आपको ढेर को इनिशियलाइज़ करना होगा।

 void gcInit(){ firstChunk = currentChunk = new gcChunk; firstChunk->next = nullptr; currentOffset = 0; chunkCount = 1; } 

यह कचरा संग्रह के कार्यान्वयन को देखने का समय है।

पहला कार्य, gcCollect, स्क्रैच से एक गुच्छा शुरू करना चाहिए, पुरानी सूची में संकेत को बचाने के लिए याद रखना चाहिए। ये रेखाएँ आरंभीकरण को लगभग दोहराती हैं।

 void gcCollect(){ //execvp("rm", "cppgc.cpp");//       . gcChunk* newFirstChunk = currentChunk = new gcChunk; currentChunk->next = nullptr; currentOffset = 0; chunkCount = 1; 

अगला, हम स्टैक पर संग्रहीत प्रत्येक पॉइंटर के साथ असेंबली प्रक्रिया शुरू करते हैं।

  for (auto i = referencesStack.begin();i != referencesStack.end(); ++i ) gcMove(*i); 

और अब सिर्फ अनावश्यक स्मृति मुक्त।

  // ,       ,     gcChunk iter = firstChunk; firstChunk = newFirstChunk; while (iter != nullptr){ gcChunk* t = iter->next; delete[] iter; iter = t; } } 

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

अंतिम स्पर्श gcMove फ़ंक्शन है।

 bool isPointer(gcHeader a){ return (a.gcData[REF_COUNT] & 1) == 0; } void gcMove(gcHeader** current){ if (*current == nullptr) return; if (isPointer(**current)){//    .   ,    . (*current) = (*current)->post_gcAddress; return; } gcHeader* new_obj = gcRawAlloc((*current)->gcData[STRUCT_SZ], (*current)->gcData[REF_COUNT]); memcpy(new_obj, (*current), sizeof(char) * (*current)->gcData[STRUCT_SZ]); gcHeader** iterator = reinterpret_cast<gcHeader**>(new_obj) + 1; (*current)->post_gcAddress = new_obj; (*current) = new_obj; int refCount = new_obj->gcData[REF_COUNT] >> 1; for (int i = 0; i < refCount; ++i, ++iterator) gcMove(iterator); } 

चलो बीच से फ़ंक्शन का विश्लेषण करते हैं। हमें लिंक को पुनर्निर्देशित करने की क्षमता की आवश्यकता है, इसलिए फ़ंक्शन को डेटा के लिए एक पॉइंटर को एक संकेतक दिया जाता है।

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

 gcHeader** iterator = reinterpret_cast<gcHeader**>(temp) + 1; 

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



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

वह सब है। यह कलेक्टर के साथ काम प्रदर्शित करने के लिए बनी हुई है।

मैं एक उदाहरण के रूप में सबसे सरल खोज पेड़ ले जाऊंगा

 struct searchTree { gcHeader gc; searchTree* left; searchTree* right; int key; static const int refCount = 2; }; 

जैसा कि पहले ही उल्लेख किया गया है, शुरुआत में एक शीर्ष होना चाहिए, और हमारे ढेर की वस्तुओं के लिए सभी बिंदुओं को शीर्षक देने के बाद।

 void stAdd(searchTree* &target, int key){ if (target == nullptr){ target = gcAlloc<searchTree>(); target->left = target->right = nullptr; target->key = key; return; } if (target->key == key) return; if (target->key < key) stAdd(target->left, key); else stAdd(target->right, key); } 

पेड़ के लिए सामान्य इसके अलावा। गौर करें कि gcAlloc का उपयोग कैसे किया जाता है।

 searchTree* stFind(searchTree* target, int key){ if (target == nullptr || target->key == key) return target; if (target->key < key) return stFind(target->left, key); else return stFind(target->right, key); } void stPrint(searchTree* t, int indent = 0){ if (t == nullptr) return; for (int i = 0; i < indent; ++i) cout << " "; cout << t << ' ' << t->key << endl; stPrint(t->left, indent + 1); stPrint(t->right, indent + 1); } void stCut(searchTree* &target, int key){ if (target == nullptr || target->key == key){ target = nullptr; return; } if (target->key < key) stCut(target->left, key); else stCut(target->right, key); } 

stFind वांछित कुंजी के साथ एक सबट्री के लिए एक लिंक देता है, StPrint सबट्रीज़ की कुंजियों और पतों को प्रिंट करता है, stCut उस सबट्री को काटता है जिसमें कुंजी संग्रहीत होती है।

अंत में, मुख्य

 int main(){ gcInit(); stackRef<searchTree> root; stAdd(root.ref, 2); stAdd(root.ref, 1); stAdd(root.ref, 3); stAdd(root.ref, 6); stAdd(root.ref, 5); stAdd(root.ref, 4); stAdd(root.ref, 8); stackRef<searchTree> additionalRef; additionalRef.ref = stFind(root.ref, 3); cout << "Before GC" << endl; cout << additionalRef.ref << ' ' << currentOffset << endl <<endl; stPrint(root.ref); cout << endl; gcCollect(); cout << "After GC" << endl; cout << additionalRef.ref << ' ' << currentOffset << endl << endl; stPrint(root.ref); cout << endl; stCut(root.ref, 5); gcCollect(); cout << "Deleted some elements and GC'd." << endl; cout << additionalRef.ref << ' ' << currentOffset << endl << endl; stPrint(root.ref); return 0; } 

 Before GC 0xd92058 224 0xd92018 2 0xd92058 3 0xd92078 6 0xd920d8 8 0xd92098 5 0xd920b8 4 0xd92038 1 After GC 0xd93108 224 0xd930e8 2 0xd93108 3 0xd93128 6 0xd93148 8 0xd93168 5 0xd93188 4 0xd931a8 1 Deleted some elements and GC'd. 0xd92038 160 0xd92018 2 0xd92038 3 0xd92058 6 0xd92078 8 0xd92098 1 

जैसा कि आप देख सकते हैं, प्रोग्रामर के लिए संरचनाओं के साथ काम करने से बहुत कुछ नहीं बदलता है। यहाँ क्या हो रहा है:
1. हम मनमाने ढंग से सर्च ट्री भरते हैं।
2. एक वस्तु के लिए कई लिंक पर जीसी कैसे प्रतिक्रिया करता है, यह जांचने के लिए तत्वों में से एक के लिए एक और स्टैक लिंक बनाएं।
3. पेड़, अतिरिक्त संदर्भ और currentOffset प्रिंट करें।
4. बेकार कचरा संग्रह।
5. पेड़ को फिर से प्रिंट करें। जरूरत पड़ने वाले सभी बिंदु बदल गए हैं।
6. एक सबट्री ट्रिम करें और फिर से कचरा संग्रह कहें। सब कुछ उसी तरह से काम करता है जैसा उसे फिर से करना चाहिए। ध्यान दें करंट ऑफ़सेट कम हो गया, और पेड़ की जड़ उसी पते पर वापस आ गई जिस पर वह पहली बार था।

निष्कर्ष

इसलिए C ++ में आप Garbage संग्राहक का उपयोग कर सकते हैं। इसके अलावा, मैं अपने इरादे के अनुसार, और यहां तक ​​कि न्यूनतम ओवरहेड के साथ काफी सुंदर हूं। मैं उन सभी चीजों को सूचीबद्ध करने की कोशिश करूंगा, जिन्हें करने की आवश्यकता है ताकि यह वास्तव में सुविधाजनक और उपयोगी हो।
पहला, संगठनात्मक बिंदु।

1. वैश्विक चर - यह, ज़ाहिर है, बिल्कुल शांत नहीं है। सब कुछ एक मानव वर्ग और / या सी ++ आवंटनकर्ता के रूप में डिजाइन किया जाना चाहिए।
2. प्रत्येक वर्ग में हेडर लगाने के लिए लगभग उदासी है। आपको केवल अमूर्त वर्ग से एक विरासत देने की आवश्यकता है, जिसमें दो विधियाँ होनी चाहिए - getSize और getLayout। उत्तरार्द्ध को उस सरणी का संदर्भ वापस करना चाहिए जिसमें सभी बिंदुओं के सापेक्ष निर्देशांक संग्रहीत हैं ("सभी लिंक शुरुआत में हैं" वाला विचार बिल्कुल भी गंभीर के लिए अच्छा नहीं है)। इस सरणी को निश्चित रूप से स्वचालित रूप से भरना चाहिए, लेकिन मुझे अभी भी पता नहीं है कि इसे कैसे लागू किया जा सकता है।

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

1. पारदर्शी।
2. एक निश्चित मेमोरी कोटा के थकावट के बाद एक अपवाद फेंक दें। यहां यह तय करना प्रोग्रामर पर निर्भर है कि वह मेमोरी को जबरदस्ती हटाए या आवंटित करे।

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

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

आप यहाँ से डाउनलोड और खेल सकते हैं ।