संदर्भ-गिनती स्मार्ट पॉइंटर्स इतने लोकप्रिय क्यों हैं?

Question

जैसा कि मैं देख सकता हूं, कई वास्तविक-दुनिया C ++ परियोजनाओं में बड़े पैमाने पर स्मार्ट पॉइंटर्स का उपयोग किया जाता है।

यद्यपि RAII और स्वामित्व हस्तांतरण का समर्थन करने के लिए कुछ प्रकार के स्मार्ट पॉइंटर्स स्पष्ट रूप से फायदेमंद होते हैं, लेकिन "कचरा संग्रह" के तरीके के रूप में , डिफ़ॉल्ट रूप से साझा पॉइंटर्स का उपयोग करने की प्रवृत्ति भी है , ताकि प्रोग्रामर को आवंटन के बारे में सोचने की ज़रूरत न पड़े ।

बोहेम जीसी जैसे उचित कचरा संग्रहकर्ता को एकीकृत करने की तुलना में साझा पॉइंटर्स अधिक लोकप्रिय क्यों हैं ? (या क्या आप बिल्कुल सहमत हैं, कि वे वास्तविक जीसी से अधिक लोकप्रिय हैं?)

मैं संदर्भ-गणना पर पारंपरिक जीसी के दो लाभों के बारे में जानता हूं:

• पारंपरिक जीसी एल्गोरिदम में संदर्भ-चक्र के साथ कोई समस्या नहीं है ।
• संदर्भ-गणना आम तौर पर एक उचित GC की तुलना में धीमी होती है।

संदर्भ-गिनती स्मार्ट पॉइंटर्स का उपयोग करने के क्या कारण हैं?

Comments

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

— मैट

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

— जॉन हैरोप

Answer 1

कचरा संग्रहण पर संदर्भ गणना के कुछ फायदे:

1. कम उपरि। कचरा संग्रहकर्ता काफी घुसपैठ हो सकता है (जैसे कि आपके प्रोग्राम को अप्रत्याशित समय पर फ्रीज करना, जबकि कचरा संग्रह चक्र प्रक्रियाएं) और काफी मेमोरी-सघन (जैसे आपकी प्रक्रिया की मेमोरी फ़ुटप्रिंट अनावश्यक रूप से कचरा-संग्रह से पहले कई मेगाबाइट्स तक बढ़ जाती है)

2. अधिक अनुमानित व्यवहार। संदर्भ की गिनती के साथ, आपको गारंटी दी जाती है कि आपकी वस्तु को तत्काल मुक्त कर दिया जाएगा क्योंकि यह अंतिम संदर्भ चला जाएगा। कचरा संग्रह के साथ, दूसरी ओर, आपकी वस्तु को "कुछ समय" मुक्त किया जाएगा, जब सिस्टम इसके चारों ओर हो जाता है। RAM के लिए यह आमतौर पर डेस्कटॉप या हल्के से लोड किए गए सर्वर पर एक बड़ी समस्या नहीं है, लेकिन अन्य संसाधनों (जैसे फ़ाइल हैंडल) के लिए आपको अक्सर संभावित संघर्षों से बचने के लिए ASAP को बंद करने की आवश्यकता होती है।

3. सरल। संदर्भ गिनती को कुछ मिनटों में समझाया जा सकता है, और एक या दो घंटे में लागू किया जा सकता है। कचरा इकट्ठा करने वाले, विशेष रूप से अच्छे प्रदर्शन वाले, बेहद जटिल हैं और बहुत से लोग उन्हें नहीं समझते हैं।

4. स्टैंडर्ड। C ++ में STL में रेफरेंस काउंटिंग (share_ptr के माध्यम से) और दोस्त शामिल हैं, जिसका अर्थ है कि अधिकांश C ++ प्रोग्रामर इससे परिचित हैं और अधिकांश C ++ कोड इसके साथ काम करेंगे। कोई मानक C ++ कचरा संग्रहकर्ता नहीं है, हालांकि, जिसका अर्थ है कि आपको एक का चयन करना होगा और आशा है कि यह आपके उपयोग के मामले में अच्छी तरह से काम करता है - और यदि ऐसा नहीं है, तो यह आपकी समस्या को ठीक करने के लिए है, भाषा की नहीं।

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

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

Comments

हाल ही में संदर्भ-गणना के कार्यान्वयन को विलंबता की कीमत पर उत्पादन GCs (30-40%) की तुलना में बहुत कम थ्रूपुट मिलते हैं । अंतर को अनुकूलन के साथ बंद किया जा सकता है जैसे कि रिफकाउंट के लिए कम बिट्स का उपयोग करना, और जब तक वे बच नहीं जाते हैं तब तक ट्रैकिंग वस्तुओं से बचना - सी ++ यह स्वाभाविक रूप से होता है यदि आप मुख्य रूप से make_sharedवापस लौटते समय। फिर भी, विलंबता, रियलटाइम अनुप्रयोगों में बड़ी समस्या है, लेकिन आमतौर पर थ्रूपुट अधिक महत्वपूर्ण है, यही वजह है कि जीसी को ट्रेसिंग का व्यापक रूप से उपयोग किया जाता है। मैं उनमें से बुरी तरह से बोलने के लिए इतनी जल्दी नहीं होगा।

— जॉन प्यूडी

मैं 'सरल' को क्विबल करूँगा: कार्यान्वयन की कुल राशि के मामले में सरल होना आवश्यक है , लेकिन उपयोग करने वाले कोड के लिए सरल नहीं है : आरसी का उपयोग करने के बारे में किसी से तुलना करना (' वस्तुओं का निर्माण करते समय यह करें और यह उन्हें नष्ट करते समय') ) कैसे (भोली, जो अक्सर पर्याप्त है) जीसी ('...') का उपयोग करें।

— आकाशवाणी

"संदर्भ गणना के साथ, आपको गारंटी दी जाती है कि आपकी वस्तु को तत्काल मुक्त कर दिया जाएगा क्योंकि यह अंतिम संदर्भ चला जाता है"। यह एक सामान्य गलत धारणा है। फ्लाइंगफ्रॉगब्लॉग .blogspot.co.uk

— जॉन

@JonHarrop: वह ब्लॉग-पोस्ट बुरी तरह से गलत है। आपको सभी टिप्पणियों को भी पढ़ना चाहिए , विशेष रूप से अंतिम एक।

— डेडुप्लिकेटर

@ जॉनरोप: हां, है। वह यह नहीं समझता है कि जीवनकाल पूर्ण गुंजाइश है जो समापन ब्रेस तक जाता है। और एफ # में अनुकूलन जो केवल टिप्पणियों के अनुसार कभी-कभी काम करता है, पहले जीवनकाल को समाप्त कर रहा है, अगर चर फिर से उपयोग नहीं किया जाता है। जो स्वाभाविक रूप से अपनी ही बुराइयाँ हैं।

— Deduplicator

Answer 2

एक GC से अच्छा प्रदर्शन प्राप्त करने के लिए, GC को ऑब्जेक्ट को मेमोरी में ले जाने में सक्षम होना चाहिए। C ++ जैसी भाषा में जहां आप मेमोरी लोकेशन के साथ सीधे इंटरैक्ट कर सकते हैं, यह बहुत असंभव है। (Microsoft C ++ / CLR की गणना नहीं होती है क्योंकि यह GC- प्रबंधित पॉइंटर्स के लिए नए सिंटैक्स का परिचय देता है और इस प्रकार प्रभावी रूप से एक अलग भाषा है।)

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

एक अच्छी, अच्छी तरह से तैयार जीसी एक महान चीज हो सकती है। लेकिन सी ++ जैसी भाषा में, लाभ न्यूनतम हैं और लागत अक्सर इसके लायक नहीं है।

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

StackOverflow पर संबंधित प्रश्न पर मेरा उत्तर भी देखें ।

Comments

रे बोहम जीसी, मुझे कभी-कभी आश्चर्य होता है कि पारंपरिक रूप से जीसी के लिए सी और सी ++ प्रोग्रामर के बीच व्यक्तिगत रूप से कितना सामान्य रूप से प्रौद्योगिकी का एक बुरा पहला प्रभाव प्रदान करके जिम्मेदार है।

— लेउशेंको

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

— user4815162342

Answer 3

जैसा कि मैं देख सकता हूं, कई वास्तविक-दुनिया C ++ परियोजनाओं में बड़े पैमाने पर स्मार्ट पॉइंटर्स का उपयोग किया जाता है।

सच है, लेकिन वास्तव में, कोड का विशाल बहुमत अब आधुनिक भाषा में कचरा संग्रहकर्ताओं के साथ लिखा गया है।

यद्यपि RAII और स्वामित्व हस्तांतरण का समर्थन करने के लिए कुछ प्रकार के स्मार्ट पॉइंटर्स स्पष्ट रूप से फायदेमंद होते हैं, लेकिन "कचरा संग्रह" के तरीके के रूप में, डिफ़ॉल्ट रूप से साझा पॉइंटर्स का उपयोग करने की प्रवृत्ति भी है, ताकि प्रोग्रामर को आवंटन के बारे में सोचने की ज़रूरत न पड़े ।

यह एक बुरा विचार है क्योंकि आपको अभी भी चक्रों के बारे में चिंता करने की आवश्यकता है।

बोहेम जीसी जैसे उचित कचरा संग्रहकर्ता को एकीकृत करने की तुलना में साझा पॉइंटर्स अधिक लोकप्रिय क्यों हैं? (या आप बिल्कुल सहमत हैं, कि वे वास्तविक जीसी से अधिक लोकप्रिय हैं?)

अरे वाह, आपकी सोच के बारे में बहुत सी बातें गलत हैं:

1. बोहम की जीसी शब्द के किसी भी अर्थ में "उचित" जीसी नहीं है। यह वास्तव में भयानक है। यह रूढ़िवादी है इसलिए यह लीक है और डिजाइन द्वारा अक्षम है। देखें: http://flyingfrogblog.blogspot.co.uk/search/label/boehm

2. साझा किए गए पॉइंटर्स, वस्तुतः, जीसी के रूप में लोकप्रिय नहीं हैं क्योंकि डेवलपर्स के विशाल बहुमत अब जीसीएलआईडी भाषाओं का उपयोग कर रहे हैं और उन्हें साझा पॉइंटर्स की कोई आवश्यकता नहीं है। सी ++ की तुलना में जॉब मार्केट में सिर्फ जावा और जावास्क्रिप्ट को देखें।

3. आप C ++ पर विचार को प्रतिबंधित करते दिखाई देते हैं क्योंकि, मुझे लगता है, आपको लगता है कि GC एक स्पर्शरेखा मुद्दा है। यह ( एक सभ्य जीसी पाने का एकमात्र तरीका नहीं है कि आप शुरुआत से ही इसके लिए भाषा और वीएम डिजाइन करें) इसलिए आप चयन पूर्वाग्रह का परिचय दे रहे हैं। जो लोग वास्तव में उचित कचरा संग्रह चाहते हैं, वे C ++ के साथ नहीं टिकते हैं।

संदर्भ-गिनती स्मार्ट पॉइंटर्स का उपयोग करने के क्या कारण हैं?

आप C ++ तक सीमित हैं, लेकिन चाहते हैं कि आपके पास स्वचालित मेमोरी प्रबंधन हो।

Comments

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

— निकोल बोलस

आपकी अंतिम पंक्ति गलत तरीके से गलत है: आप C ++ में हैं और खुशी है कि आप GC से निपटने के लिए मजबूर नहीं हैं और यह संसाधनों को मुक्त करने में देरी कर रहा है। एक कारण यह है कि Apple GC को पसंद नहीं करता है, और GC'd भाषाओं के लिए सबसे महत्वपूर्ण दिशानिर्देश है: कोई भी कचरा तब तक न बनाएं जब तक कि आपके पास निष्क्रिय संसाधनों के gobs न हों या यह मदद न कर सके।

— Deduplicator

@ जॉनह्रोप: तो, जीसी के साथ और उसके बिना समान छोटे कार्यक्रमों की तुलना करें, जो स्पष्ट रूप से किसी भी पक्ष के लाभ के लिए खेलने के लिए नहीं उठाए गए हैं। आपको कौन सी स्मृति की आवश्यकता है?

— Deduplicator

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

— जॉन हैरोप

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

— डेडुप्लिकेटर

Answer 4

MacOS X और iOS में, और ऑब्जेक्टिव-सी या स्विफ्ट का उपयोग करने वाले डेवलपर्स के साथ, संदर्भ की गिनती लोकप्रिय है क्योंकि इसे स्वचालित रूप से नियंत्रित किया जाता है, और कचरा संग्रहण का उपयोग काफी कम हो गया है क्योंकि Apple अब इसका समर्थन नहीं करता है (मुझे बताया गया है कि ऐप का उपयोग कर कचरा संग्रह अगले मैकओएस एक्स संस्करण में टूट जाएगा, और कचरा संग्रह कभी भी आईओएस में लागू नहीं किया गया था)। मुझे वास्तव में गंभीरता से संदेह है कि जब यह उपलब्ध था तब कचरा संग्रहण का उपयोग करने वाला बहुत सा सॉफ्टवेयर था।

कचरा संग्रहण से छुटकारा पाने का कारण: इसने कभी भी सी-शैली के वातावरण में मज़बूती से काम नहीं किया, जहाँ पॉइंटर्स कचरा इकट्ठा करने वाले क्षेत्रों तक "पलायन" कर सकते हैं। Apple दृढ़ता से विश्वास करता है और मानता है कि संदर्भ गिनती तेज है। (आप रिश्तेदार गति के बारे में यहां कोई भी दावा कर सकते हैं, लेकिन कोई भी एप्पल को मनाने में सक्षम नहीं है)। और अंत में, किसी ने कचरा संग्रह का उपयोग नहीं किया।

पहली बात यह है कि कोई भी मैकओएस एक्स या आईओएस डेवलपर सीखता है कि संदर्भ चक्र को कैसे संभालना है, इसलिए यह एक असली डेवलपर के लिए कोई समस्या नहीं है।

Comments

जिस तरह से मैं इसे समझता हूं, यह नहीं था कि यह एक सी जैसा माहौल है जो चीजों का फैसला करता है लेकिन यह कि जीसी अनिश्चित है और स्वीकार्य प्रदर्शन करने के लिए बहुत अधिक मेमोरी की आवश्यकता होती है, और सर्वर / डेस्कटॉप के बाहर हमेशा एक छोटा सा निशान होता है।

— Deduplicator

डिबगिंग क्यों कचरा कलेक्टर एक वस्तु को नष्ट कर दिया है कि मैं अभी भी उपयोग कर रहा था (एक दुर्घटना के लिए अग्रणी) यह मेरे लिए तय किया :-)

— gnasher729

अरे हाँ, यह भी होगा। क्या आपको अंत में पता चला कि क्यों?

— डेडुप्लिकेटर

हां, यह कई यूनिक्स कार्यों में से एक था जहां आप एक "संदर्भ" के रूप में एक शून्य * पास करते हैं जो फिर आपको कॉलबैक फ़ंक्शन में वापस दिया जाता है; शून्य * वास्तव में एक उद्देश्य-सी वस्तु थी, और कचरा संग्रहकर्ता को यह पता नहीं चला कि वस्तु यूनिक्स कॉल में दूर धराशायी हो गई थी। कॉलबैक कहा जाता है, शून्य * को ऑब्जेक्ट *, kaboom!

— gnasher729

Answer 5

C ++ में कचरा संग्रहण का सबसे बड़ा नुकसान यह है, कि सही होने के लिए यह असंभव है:

• सी ++ में, पॉइंटर्स अपने स्वयं के दीवार वाले समुदाय में नहीं रहते हैं, उन्हें अन्य डेटा के साथ मिलाया जाता है। इस प्रकार, आप किसी अन्य डेटा से एक पॉइंटर को अलग नहीं कर सकते हैं जो कि केवल एक बिट पैटर्न होता है जिसे एक मान्य पॉइंटर के रूप में व्याख्या किया जा सकता है।

  परिणाम: कोई भी C ++ कचरा संग्रहकर्ता उन वस्तुओं को लीक करेगा जिन्हें एकत्र किया जाना चाहिए।

• C ++ में, आप सूचक को व्युत्पन्न बिंदुओं के लिए अंकगणित कर सकते हैं। जैसे, यदि आपको एक ब्लॉक की शुरुआत के लिए कोई संकेतक नहीं मिलता है, तो इसका मतलब यह नहीं है कि उस ब्लॉक को संदर्भित नहीं किया जा सकता है।

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

  नोट: कोई C ++ कचरा संग्रहकर्ता कोड को इस तरह से चाल के साथ संभाल सकता है:

  int* array = new int[7];
  array--;    //undefined behavior, but people may be tempted anyway...
  for(int i = 1; i <= 7; i++) array[i] = i;

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

Comments

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

— निकोल बोलस

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

— Bwmat

@Bwmat "सम"? किसी फ़ाइल की ओर संकेत लिखना जैसे कि थोड़ा सा लगता है ... दूर की कौड़ी है। वैसे भी, एक ही गंभीर समस्या वस्तुओं को ढेर करने के लिए संकेत देती है, वे तब जा सकते हैं जब आप कोड में फ़ाइल से सूचक को कहीं और वापस पढ़ते हैं! अमान्य सूचक मूल्य deserializing है अपरिभाषित व्यवहार, ऐसा नहीं है।

— हाइड

यदि निश्चित रूप से, आपको सावधान रहना होगा यदि आप ऐसा कुछ कर रहे हैं। इसका एक उदाहरण था कि सामान्य तौर पर, एक कचरा संग्रहकर्ता C ++ में सभी मामलों में 'ठीक से' काम नहीं कर सकता (भाषा को बदले बिना)

— Bwmat

@ gnasher729: एहम, नहीं? पास्ट-एंड-पॉइंटर्स बिल्कुल ठीक हैं?

— डेडुप्लिकेटर