C और C ++ जैसी भाषाओं में कचरा संग्रह क्यों नहीं है, जबकि जावा करता है? [बन्द है]

57

वैसे, मुझे पता है कि सी + के लिए मॉलोक / फ्री जैसी चीजें हैं, और सी ++ में मेमोरी मैनेजमेंट के लिए नया / यूज-ए-डिस्ट्रक्टर है, लेकिन मैं सोच रहा था कि इन भाषाओं में "नए अपडेट" क्यों नहीं हैं जो उपयोगकर्ता को अनुमति देते हैं मेमोरी को मैन्युअल रूप से प्रबंधित करने का विकल्प है, या सिस्टम को स्वचालित रूप से (कचरा संग्रह) करने का विकल्प है?

कुछ हद तक एक newb-ish सवाल है, लेकिन केवल एक साल के लिए सीएस में है।

garbage-collection

— डार्क टेम्पलर
स्रोत

9

हमें इस सेमेस्टर के iPhone विकास में एक मॉड्यूल मिला है। 2 साल तक एंड्रॉइड के लिए ऐप को कोड करने के बाद, इस सवाल ने अधिकांश वर्ग को बहुत मुश्किल से मारा। केवल अब हम देखते हैं कि कितने घंटे जावा ने वास्तव में हमें खराब मेमोरी प्रबंधन त्रुटियों को ट्रैक करने और बॉयलरप्लेट कोड लिखने में नहीं होने के लिए बचाया है।

— स्यामई

7

@NullUserException, चूंकि यह मेमोरी को पुनः प्राप्त करने का एक तरीका निर्दिष्ट नहीं करता है जो बहुत अधिक जीसी का अर्थ है।

— विंस्टन एवर्ट

1

@ bizso09: क्या आपने ARC को अभी तक देखा है? जब आपको संदर्भ गणना के लिए सिस्टम-सपोर्ट मिला है, तो आपको धीमे / वसा / गैर-नियतांक जीसी की कोई आवश्यकता नहीं है: डेवलपर

— ।apple.com

3

इस अच्छे सवाल का जवाब धार्मिक बकवास है।

— abatishchev

1

C और C ++ में, पॉइंटर लेना संभव है, इसे इंट में डालना और इसमें एक नंबर जोड़ना है। बाद में संख्या को इंट से हटा दें और परिणाम को एक पॉइंटर पर वापस लाएं। आपको पहले जैसा ही पॉइंटर मिलेगा। जीसी को लागू करने में सौभाग्य जो उस स्मृति को इकट्ठा नहीं करता है जबकि इसका पता केवल उस चर में संग्रहीत किया जाता है जिसमें दूसरा मूल्य भी होता है। मुझे पता है कि उदाहरण मूर्खतापूर्ण है लेकिन XOR से जुड़ी सूची कुछ इसी तरह का उपयोग करती है। मैं इसे उत्तर के रूप में पोस्ट करूंगा लेकिन सवाल बंद है।

— मैरियन स्पैनिक

71

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

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

— काइलबेन
स्रोत

26

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

— काइलबेन

22

- आधुनिक जीसी का न तो ट्रैक आवंटन है और न ही संदर्भों की गिनती। वे ढेर पर वर्तमान में सब कुछ से एक ग्राफ का निर्माण और सिर्फ गाढ़ा और बाकी सब कुछ (सरलीकृत) पोंछ, और जीसी सामान्य रूप से परिणाम में कम भाषा जटिलता। यहां तक कि प्रदर्शन लाभ संदिग्ध है।

— जोएल कोएहॉर्न

13

Er, @kylben, भाषा में स्वचालित GC पके होने का पूरा बिंदु यह है कि ज़ोंबी वस्तुओं को संदर्भित करना असंभव हो जाता है , क्योंकि GC केवल उन वस्तुओं को मुक्त करता है जो संदर्भ के लिए असंभव हैं! जब आप मैन्युअल मेमोरी प्रबंधन के साथ गलतियाँ करते हैं, तो आप जिस तरह की बात कर रहे हैं, उसके बारे में आपको तरह-तरह के कीड़े मिलते हैं।

— बेन

14

-1, GC संदर्भों की गणना नहीं करता है। साथ ही, आपकी मेमोरी उपयोग और आवंटन योजना के आधार पर, एक GC तेजी से (मेमोरी उपयोग में ओवरहेड के साथ) हो सकता है। तो प्रदर्शन के बारे में तर्क भी बहुत कम है। केवल धातु के करीब वास्तव में एक वैध बिंदु है।

— deadalnix

14

न तो जावा और न ही सी # उपयोग संदर्भ गिनती: जीसी संदर्भ गिनती के आधार पर योजनाओं की तुलना में बहुत आदिम कर रहे हैं और आधुनिक कचरा कलेक्टरों की तुलना में बहुत खराब प्रदर्शन (मुख्य रूप से, क्योंकि वे स्मृति करने की जरूरत है जब भी आप एक संदर्भ कॉपी संदर्भ में गिना जाता है को बदलने के लिए लिखते हैं!)

— mikera

44

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

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

— चार्ल्स ई। ग्रांट
स्रोत

2

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

— शिवन ड्रैगन

2

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

— लुआण

1

@Luaan मैं कहूंगा कि "मेमोरी मैनेजमेंट" होने की एक बहुत ही उदार परिभाषा है "जब तक आप ढेर से बाहर आवंटित करना शुरू नहीं करते हैं, तब तक आप ठीक हैं और बांके हैं। यह ढेर आवंटन है जो चीजों को गड़बड़ कर देता है", यह एक कार कहने जैसा है। पूरी तरह से अच्छा हवाई जहाज, यह अभी उड़ान भरने में सक्षम नहीं है।

— चार्ल्स ई। ग्रांट

1

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

— लुआं

"कोई भी मानक अनुपालन कार्यान्वयन" केवल मानक अनुपालन मेजबान पर्यावरण कार्यान्वयन के लिए सही नहीं है। 8 या 16-बिट एम्बेडेड माइक्रोकंट्रोलर के लिए कुछ प्लेटफार्म / मानक पुस्तकालय, प्रदान नहीं करते हैं malloc()या free()। (उदाहरण PIC के लिए MLAP-Compilers हैं)

— 12431234123412341234123

32

वास्तविक उत्तर यह है कि सुरक्षित, कुशल कचरा संग्रहण तंत्र बनाने का एकमात्र तरीका अपारदर्शी संदर्भों के लिए भाषा-स्तर का समर्थन है । (या, इसके विपरीत, प्रत्यक्ष स्मृति हेरफेर के लिए भाषा-स्तर के समर्थन की कमी है।)

जावा और C # कर सकते हैं क्योंकि उनके पास विशेष संदर्भ प्रकार हैं जिन्हें हेरफेर नहीं किया जा सकता है। यह रनटाइम को मेमोरी में आबंटित ऑब्जेक्ट्स जैसी चीजों को करने की स्वतंत्रता देता है , जो एक उच्च-प्रदर्शन जीसी कार्यान्वयन के लिए महत्वपूर्ण है।

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

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

ध्यान दें कि एक उच्च-प्रदर्शन जीसी की एक कुंजी यह है कि विशेष वर्ग के संदर्भों के लिए भाषा का समर्थन होना चाहिए। C के पास यह भाषा समर्थन नहीं है और यह कभी नहीं होगा; क्योंकि C ++ में ऑपरेटर ओवरलोडिंग है, यह GC'd पॉइंटर प्रकार का अनुकरण कर सकता है, हालांकि इसे सावधानी से करना होगा। वास्तव में, जब Microsoft ने C ++ की अपनी बोली का आविष्कार किया, जो CLR (.NET रनटाइम) के तहत चलेगा, तो उन्हें "C # -स्टाइल संदर्भ" (उदाहरण के लिए Foo^) के लिए एक नया वाक्यविन्यास लिखना होगा, ताकि उन्हें "C ++ - शैली संदर्भ" से अलग किया जा सके। (जैसे Foo&)।

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

दिन के अंत में, उत्तर वास्तव में एक भाषा डिजाइन सुविधा के लिए उबलता है। C ने एक विकल्प बनाया, C ++ ने एक ऐसा विकल्प बनाया जो इसे C के साथ पीछे-संगत होने में सक्षम बनाता है जबकि अभी भी विकल्प प्रदान कर रहे हैं जो कि अधिकांश उद्देश्यों के लिए पर्याप्त हैं, और Java और C # ने एक अलग विकल्प बनाया है जो C के साथ असंगत है लेकिन इसके लिए भी पर्याप्त है अधिकांश उद्देश्य। दुर्भाग्य से, कोई चांदी की गोली नहीं है, लेकिन विभिन्न विकल्पों से परिचित होने के कारण आप जिस भी कार्यक्रम को बनाने की कोशिश कर रहे हैं, उसके लिए सही चयन करने में मदद मिलेगी।

— डैनियल Pryden
स्रोत

4

यह प्रश्न का वास्तविक उत्तर है

— coredump

1

C ++ भाग के लिए, आजकल आप एसटीडी पर गौर करना चाहिए :: unique_ptr और std :: कदम :)

— निक्लास लार्ससन

@NiclasLarsson: मुझे यकीन नहीं है कि मैं आपकी बात समझता हूँ। क्या आप कह रहे हैं कि std::unique_ptr"अपारदर्शी संदर्भों के लिए भाषा-स्तरीय समर्थन" है? (यह मेरे समर्थन का मतलब नहीं था, और मुझे भी नहीं लगता कि यह पर्याप्त है जब तक कि प्रत्यक्ष मेमोरी हेरफेर के लिए समर्थन C ++ से हटा नहीं दिया गया था।) मैं अपने जवाब में स्मार्ट पॉइंटर्स का उल्लेख करता हूं, और मैं std:unique_ptrएक स्मार्ट पॉइंटर पर विचार करूंगा। , क्योंकि यह वास्तव में संदर्भ गणना करता है, यह केवल उन विशेष मामलों का समर्थन करता है जहां संदर्भों की संख्या शून्य या एक है (और std::moveयह संदर्भ गणना अद्यतन तंत्र है)।

— डैनियल प्रेडेन

std::unique_ptrसंदर्भ संख्या नहीं है और std::moveइसका संदर्भ से कोई लेना-देना नहीं है (इसलिए "नहीं" प्रदर्शन हिट)। हालांकि मैं आपकी बात देखता हूं, क्योंकि std::shared_ptrएक संदर्भ गणना है जो कि अनुमानित रूप से अपडेट की गई है std::move:)

— निकल्स लार्सन

2

@ माइक76: आवंटन पक्ष पर, जीसी आवंटनकर्ता स्टैक आवंटन के रूप में तेजी से काम करेगा, और जीसी एक ही समय में हजारों वस्तुओं को हटा सकता है। कोई फर्क नहीं पड़ता कि आप एक रेफरी-गिनती कार्यान्वयन के साथ क्या करते हैं, आवंटन और निपटारा कभी भी तेजी से mallocऔर नहीं होगा free। तो हाँ, एक जीसी काफी तेजी से हो सकता है। (ध्यान दें कि मैंने कहा "हो सकता है" - निश्चित रूप से प्रत्येक कार्यक्रम का सटीक प्रदर्शन कई कारकों से प्रभावित होता है।)

— डैनियल प्राइडेन

27

क्योंकि, C ++ की शक्ति का उपयोग करते समय, कोई आवश्यकता नहीं है।

हर्ब सटर: " मैंने वर्षों में डिलीट नहीं लिखा है। "

देखने के आधुनिक सी ++ कोड लेखन: कैसे सी ++ पिछले कुछ वर्षों में विकसित किया गया है 21:10

यह कई अनुभवी C ++ प्रोग्रामर को आश्चर्यचकित कर सकता है।

— लायर कोगन का खुलासा किया
स्रोत

दिलचस्प। आज के लिए मेरी पठन सामग्री।

— सर्फ़स

बाह, एक वीडियो। लेकिन कभी कम नहीं, पहले से ही दिलचस्प।

— सर्फस

2

दिलचस्प वीडियो 21 मिनट में और 55 मिनट सबसे अच्छे बिट्स थे। बहुत बुरा WinRT कॉल अभी भी C ++ / CLI bumpf लग रहा था।

— gbjbaanb

2

@ dan04: यह सच है। लेकिन फिर, यदि आप सी में लिखते हैं, तो आपको वही मिलता है जो आप मांगते हैं।

— डेडएमजीन

6

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

— तमसे सजेलेई

15

"ऑल" एक कचरा कलेक्टर एक ऐसी प्रक्रिया है जो समय-समय पर जांच करती है कि यह देखने के लिए कि क्या स्मृति में कोई अपरिचित वस्तुएं हैं और यदि उन्हें हटा दिया जाता है। (हां, मुझे पता है कि यह एक स्थूल निरीक्षण है)। यह भाषा की संपत्ति नहीं है, बल्कि रूपरेखा है।

C और C ++ के लिए लिखे गए कचरा संग्रहकर्ता हैं - उदाहरण के लिए यह एक ।

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

— एफ
स्रोत

1

लेकिन लिखे गए भविष्य के कार्यक्रम कचरा कलेक्टर का उपयोग करना शुरू करेंगे, नहीं?

— डार्क टेम्पलर

5

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

— tdammers

4

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

— Jan Hudec

2

@ ThorbjørnRavnAndersen: मैं एक मान्य C प्रोग्राम लिख सकता हूं जो पॉइंटर्स को इस तरह से स्टोर करता है कि कोई भी कचरा संग्रहकर्ता उन्हें कभी नहीं ढूंढ सके। यदि आप कूड़ा उठाने वाले को हुक देते हैं mallocऔर freeआप मेरा सही कार्यक्रम तोड़ देंगे।

— बेन वोइगट

2

@ ThorbjørnRavnAndersen: नहीं, मैं freeतब तक फोन नहीं करूंगा, जब तक मैं इसके साथ नहीं किया जाता। लेकिन जब तक मैं स्पष्ट रूप से कॉल नहीं करता, तब तक आपका प्रस्तावित कचरा संग्रहकर्ता स्मृति को मुक्त नहीं करता है free।

— बेन वोइग्ट

12

C को उस युग में डिज़ाइन किया गया था जब कचरा संग्रह मुश्किल से एक विकल्प था। यह उन उपयोगों के लिए भी था जहां कचरा संग्रह आम तौर पर काम नहीं करेगा - नंगे धातु, न्यूनतम स्मृति और न्यूनतम रनटाइम समर्थन के साथ वास्तविक समय का वातावरण। याद रखें कि सी पहले यूनिक्स के लिए कार्यान्वयन भाषा थी, जो 64 * के * बाइट्स मेमोरी के साथ पीडीपी -11 पर चलती थी । सी ++ मूल रूप से सी के लिए एक विस्तार था - पसंद पहले से ही बनाई गई थी, और मौजूदा भाषा पर कचरा संग्रह को इकट्ठा करना बहुत कठिन है। यह उस तरह की चीज है जिसे ग्राउंड फ्लोर से बनाया जाना है।

— ddyer
स्रोत

9

मेरे पास सटीक उद्धरण नहीं हैं, लेकिन ब्रेज़ने और हर्ब सटर दोनों ही लाइनों के साथ कुछ कहते हैं:

C ++ को कचरा संग्राहक की आवश्यकता नहीं है, क्योंकि इसमें कोई कचरा नहीं है।

आधुनिक C ++ में आप स्मार्ट पॉइंटर्स का उपयोग करते हैं और इसलिए कोई कचरा नहीं है।

— ronag
स्रोत

1

स्मार्ट पॉइंटर्स क्या हैं?

— डार्क टमप्लर

11

अगर यह इतना आसान होता, तो कोई भी किसी जीसी को लागू नहीं करता।

— deadalnix

7

@ डेडलनिक्स: सही है, क्योंकि कोई भी कभी भी कुछ भी जटिल, धीमा, फूला हुआ या अनावश्यक नहीं करता है। सभी सॉफ्टवेयर हर समय 100% कुशल है, है ना?

— ज़च

5

@deadalnix - मेमोरी प्रबंधन के लिए C ++ का दृष्टिकोण कचरा लेने वालों की तुलना में नया है। RAII का आविष्कार Bjarne Stroustrup ने C ++ के लिए किया था। विध्वंसक सफाई एक पुराना विचार है, लेकिन अपवाद-सुरक्षा सुनिश्चित करने के नियम महत्वपूर्ण हैं। मुझे नहीं पता कि वास्तव में कब इस विचार का पहली बार वर्णन किया गया था, लेकिन पहला सी ++ मानक 1998 में अंतिम रूप से तैयार किया गया था, और स्ट्रॉस्ट्रैपअप्स "डिज़ाइन और इवोल्यूशन ऑफ सी ++" को 1994 तक प्रकाशित नहीं किया गया था, और अपवाद सी ++ के लिए एक अपेक्षाकृत हाल के अतिरिक्त थे - 1990 में "एनोटेट सी ++ संदर्भ मैनुअल" के प्रकाशन के बाद, मुझे विश्वास है। जीसी का आविष्कार 1959 में लिस्प के लिए किया गया था।

— स्टीव ३१

1

@deadalnix - क्या आप जानते हैं कि कम से कम एक जावा वीएम ने एक संदर्भ-गिनती जीसी का उपयोग किया था जो स्मार्ट ++ पॉइंटर क्लास का उपयोग करके सी + + शैली RAII का उपयोग करके लागू किया जा सकता है - ठीक है क्योंकि यह मौजूदा वीएम के मल्टीथ्रेडेड कोड के लिए अधिक कुशल था? Www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf देखें। एक कारण जिसे आप C ++ में अभ्यास में नहीं देखते हैं, वह सामान्य GC संग्रह है - यह चक्रों को एकत्र कर सकता है, लेकिन चक्रों की उपस्थिति में एक सुरक्षित विध्वंसक क्रम का चयन नहीं कर सकता है, और इस प्रकार विश्वसनीय विध्वंसक सफाई सुनिश्चित नहीं कर सकता है।

— स्टीव 314

8

आप पूछते हैं कि वैकल्पिक कचरा संग्रहकर्ता को शामिल करने के लिए इन भाषाओं को अपडेट क्यों नहीं किया गया है।

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

— विंस्टन इवर्ट
स्रोत

6

क्या आप कचरा संग्रहण वाली भाषा में डिवाइस हैंडलर लिखने की कल्पना कर सकते हैं? जीसी चलने के दौरान कितने बिट्स लाइन के नीचे आ सकते हैं?

या एक ऑपरेटिंग सिस्टम? आप कर्नेल शुरू करने से पहले कचरा संग्रहण कैसे शुरू कर सकते हैं?

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

— जेम्स एंडरसन
स्रोत

2

उच्च स्तर के लिए अच्छा है? मैंने अपने कीबोर्ड पर अपना ड्रिंक सर्व किया।

— डेडएमजीन

5

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

— स्टीव 314

कुछ प्रबंधित ऑपरेटिंग सिस्टम हैं, और वे अच्छी तरह से काम करते हैं। वास्तव में, जब आप पूरे सिस्टम को प्रबंधित करते हैं, तो वास्तविक जीवन के परिदृश्यों में अनवांटेड कोड की तुलना में तेज़ होने तक, प्रबंधित कोड ड्रॉप का उपयोग करने से प्रदर्शन भी कम हो जाता है। बेशक, वे सभी "रिसर्च ओएस" हैं - मौजूदा ओएस के भीतर पूरी तरह से वर्चुअलाइज्ड अनवांटेड ओएस बनाने के अलावा मौजूदा अनवांटेड कोड के साथ संगत करने का कोई तरीका नहीं है। Microsoft ने कुछ बिंदु पर सुझाव दिया कि वे Windows सर्वर को उनमें से किसी एक के साथ बदल सकते हैं, हालाँकि, जैसा कि अधिक से अधिक सर्वर कोड .NET पर लिखा गया है।

— लुआण

6

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

दूसरा सवाल यह है कि C और C ++ में कचरा बीनने वाले क्यों नहीं हैं। ठीक है, मुझे पता है कि C ++ में उनके आस-पास के कुछ जोड़े हैं लेकिन वे वास्तव में लोकप्रिय नहीं हैं क्योंकि वे एक ऐसी भाषा से निपटने के लिए मजबूर हैं जो पहले स्थान पर GC-ed के लिए डिज़ाइन नहीं की गई थी, और जो लोग अभी भी C ++ का उपयोग करते हैं यह आयु वास्तव में उस तरह की नहीं है जो GC को याद करती है।

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

— hugomg
स्रोत

1

प्रोग्रामर.से या एसओ पर कहीं, एक दावा है कि किसी ने मुझसे कहा था कि कोई व्यक्ति स्व-बूटस्ट्रैपिंग कचरा एकत्र करने वाली चीज़ पर काम कर रहा था - IIRC मूल रूप से एक GC भाषा का उपयोग करके VM को कार्यान्वित कर रहा है, एक बूटस्ट्रैपिंग सबसेट के साथ ही GC लागू करने के लिए उपयोग किया जाता है। मैं नाम भूल गया। जब मैंने इसे देखा, तो यह पता चला कि वे मूल रूप से कभी भी उप-बिना-जीसी से काम-जीसी स्तर तक छलांग हासिल नहीं कर सकते थे। यह है सिद्धांत में संभव है, लेकिन है AFAIK यह व्यवहार में हासिल किया गया कभी नहीं - यह निश्चित रूप से चीजों को मुश्किल तरीके से करने का एक मामला है।

— स्टीव 314

@ स्टीव ३१४: मुझे यह देखकर अच्छा लगेगा कि यदि आपको कभी यह याद रहे कि आपने इसे कहाँ पाया है!

— hugomg

मिल गया! के लिए टिप्पणियों देखें stackoverflow.com/questions/3317329/... क्लेन वी एम का जिक्र है। इसे खोजने में समस्या का हिस्सा - सवाल बंद कर दिया गया था।

— स्टीव 314

BTW - मुझे @missingno के साथ अपनी टिप्पणी शुरू करने में असमर्थ लगता है - क्या देता है?

— स्टीव ३१

@ steve314: इस प्रश्न के उत्तर से जुड़े होने के बाद, मुझे पहले से ही सभी टिप्पणियों के लिए एक सूचना प्राप्त है। इस मामले में @ -पोस्ट करना बेमानी होगा और एसई द्वारा अनुमति नहीं दी जाती है (मुझसे पूछें कि हालांकि क्यों नहीं)। (हालांकि असली वजह यह है कि मेरा नंबर गायब है)

— hugomg

5

सहित विभिन्न मुद्दे हैं ...

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

मूल रूप से, आंशिक रूप से यह भाषाओं की उम्र के बारे में है, लेकिन हमेशा गैर-जीसी भाषाओं के लिए एक जगह होगी - भले ही यह एक जगह पर थोड़ा सा हो। और गंभीरता से, सी ++ में, जीसी की कमी एक बड़ी बात नहीं है - आपकी स्मृति को अलग तरीके से प्रबंधित किया जाता है, लेकिन यह अप्रबंधित नहीं है।

Microsofts प्रबंधित C ++ में कम से कम जीसी और नॉन-जीसी को एक ही एप्लिकेशन में मिलाने की कुछ क्षमता है, जिससे प्रत्येक से फायदे का मिश्रण और मैच हो सकता है, लेकिन मुझे यह कहने का अनुभव नहीं है कि व्यवहार में यह कितना अच्छा है।

मेरे से संबंधित उत्तरों के लिए पुनः-लिंकिंग लिंक ...

— 314 का अवलोकन किया
स्रोत

4

डीएमए-सक्षम हार्डवेयर के लिए ड्राइवरों को विकसित करने के लिए उपयोग की जाने वाली सिस्टम भाषा के साथ कचरा संग्रह मौलिक रूप से असंगत है।

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

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

तो अब आपको immobile DMA बफ़र्स और GC-प्रबंधित ऑब्जेक्ट्स के मिश्रण की आवश्यकता होगी, जिसका अर्थ है कि आपके पास दोनों के सभी नुकसान हैं।

— बेन वायगट
स्रोत

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

— स्टीव 314

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

— बेन वोइगट

2

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

— स्टीव

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

— स्टीव ३४

3

क्योंकि, C & C ++ अपेक्षाकृत निम्न स्तर की भाषाएं हैं, जो सामान्य प्रयोजन के लिए हैं, उदाहरण के लिए, एक एम्बेडेड सिस्टम में 1MB मेमोरी के साथ 16-बिट प्रोसेसर पर चलने के लिए, जो कि जीसी के साथ मेमोरी बर्बाद नहीं कर सकता है।

— Petruza
स्रोत

1

"अंतःस्थापित प्रणाली"? जिस समय C को मानकीकृत (1989) किया गया था, उसमें 1 MB मेमोरी वाले PC को संभालने में सक्षम होने की आवश्यकता थी ।

— dan04

मैं सहमत हूं, मैं एक अधिक वर्तमान उदाहरण का हवाला दे रहा था।

— पेत्रुजा

1 एमबी ??? पवित्र विद्वान, जो कभी भी ज्यादा RAM की आवश्यकता होगी? </ बिलगेट्स>

— मार्क के कोवन

2

C ++ और C. में कचरा संग्रहकर्ता हैं। यह सुनिश्चित नहीं करता है कि यह C में कैसे काम करता है, लेकिन C ++ में आप RTTI का लाभ उठाने के लिए अपने ऑब्जेक्ट ग्राफ को गतिशील रूप से खोज सकते हैं और कचरा संग्रह के लिए उपयोग कर सकते हैं।

मेरी जानकारी के लिए, आप एक कचरा संग्रहकर्ता के बिना जावा नहीं लिख सकते। थोड़ी खोज ने इसे बदल दिया ।

जावा और सी / सी ++ के बीच महत्वपूर्ण अंतर यह है कि सी / सी ++ में विकल्प हमेशा आपका होता है, जबकि जावा में आप अक्सर बिना डिजाइन के विकल्प छोड़ देते हैं।

— डीओएस
स्रोत

और यह भी कि समर्पित कचरा संग्राहकों को बेहतर तरीके से लागू किया जाता है, और अधिक कुशल और भाषा में बेहतर रूप से फिट किया जाता है। :)

— अधिकतम

नहीं, आप C / C ++ में ऑब्जेक्ट ग्राफ को गतिशील रूप से खोजने के लिए RTTI का उपयोग नहीं कर सकते हैं: यह सादे पुराने डेटा ऑब्जेक्ट हैं जो सब कुछ खराब करते हैं। एक सादे पुराने डेटा ऑब्जेक्ट में संग्रहीत कोई भी RTTI जानकारी नहीं है जो किसी कचरा संग्रहकर्ता को उस ऑब्जेक्ट के भीतर पॉइंटर्स और नॉन-पॉइंटर्स के बीच अंतर करने की अनुमति देगा। इससे भी बदतर, पॉइंटर्स को सभी हार्डवेयर पर पूरी तरह से संरेखित करने की आवश्यकता नहीं है, इसलिए, एक 16 बाइट ऑब्जेक्ट को देखते हुए, 9 संभावित स्थान हैं जिन्हें 64 बिट पॉइंटर संग्रहीत किया जा सकता है, जिनमें से केवल दो ओवरलैप नहीं होते हैं।

— सेमीस्टर

2

यह प्रदर्शन और सुरक्षा के बीच का व्यापार है।

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

लाभ यह है कि निश्चित रूप से, कोई भाषा बिना पॉइंटर्स या मेमोरी लीक के बिना भाषा का निर्माण कर सकता है, इसलिए एक सही कोड का उत्पादन करने की अधिक संभावना है।

इन बहसों के लिए कभी-कभी थोड़ी 'धार्मिक' बढ़त हो सकती है - चेतावनी!

— adrianmcmenamin
स्रोत

1

यहाँ GC की अंतर्निहित समस्याओं की एक सूची दी गई है, जो इसे C जैसी सिस्टम भाषा में अनुपयोगी बनाती है:

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

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

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

C और C ++ ऐसी भाषाएं हैं जो सभी संभव उपयोग मामलों का समर्थन करने के लिए बनाई गई हैं। और, जैसा कि आप देख रहे हैं, इनमें से कई का उपयोग कचरा संग्रहण द्वारा किया जाता है। इसलिए, इन उपयोग मामलों का समर्थन करने के लिए, C / C ++ कचरा एकत्र नहीं किया जा सकता है।

— cmaster
स्रोत