.net प्रबंधित मेमोरी हैंडल मूल्य प्रकार ऑब्जेक्ट्स के अंदर कैसे करता है?

Question

public class MyClass 
{ 
    public int Age; 
    public int ID; 
} 

public void MyMethod() 
{ 
    MyClass m = new MyClass(); 
    int newID; 
} 

मेरी समझ के लिए, निम्न सत्य है:

1. संदर्भ मीटर ढेर पर रहता है और गुंजाइश जब MyMethod() बाहर निकलता से बाहर चला जाता है।
2. मूल्य प्रकार नया आईडी ढेर पर रहता है और जब MyMethod() निकलता है तो दायरे से बाहर चला जाता है।
3. नए ऑपरेटर द्वारा बनाई गई वस्तु ढेर में रहती है और जीसी द्वारा पुनः प्राप्त करने योग्य हो जाती है जब MyMethod() निकलता है, मानते हैं कि ऑब्जेक्ट का कोई अन्य संदर्भ मौजूद नहीं है। वस्तुओं के भीतर ढेर या ढेर पर रहते
   1. Do मूल्य प्रकार:

   यहाँ मेरे सवाल है?

4. किसी ऑब्जेक्ट में बॉक्सिंग/अनबॉक्सिंग मान प्रकार किसी चिंता का विषय है?
5. क्या इस विषय पर कोई विस्तृत, अभी तक समझने योग्य संसाधन हैं?

तार्किक रूप से, मुझे लगता है कि कक्षाओं के भीतर मूल्य प्रकार ढेर में होंगे, लेकिन मुझे यकीन नहीं है कि उन्हें वहां जाने के लिए बॉक्स किया जाना है या नहीं।

संपादित करें:

इस विषय के लिए पढ़ने सुझाव:

1. CLR Via C# by Jeffrey Richter
2. Essential .NET by Don Box

Answer 1

कक्षा के लिए मान-प्रकार मान प्रबंधित ढेर में ऑब्जेक्ट उदाहरण के साथ रहने के लिए है। एक विधि के लिए थ्रेड का ढेर केवल एक विधि की अवधि के लिए रहता है; मूल्य तब तक कैसे रह सकता है जब यह केवल उस ढेर के भीतर मौजूद हो?

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

उदाहरण के लिए, एक फ़ील्ड के साथ एक साधारण वर्ग लें।

public class EmbeddedValues 
{ 
    public int NumberField; 
} 

और इसके साथ, एक साधारण परीक्षण वर्ग।

public class EmbeddedTest 
{ 
    public void TestEmbeddedValues() 
    { 
    EmbeddedValues valueContainer = new EmbeddedValues(); 

    valueContainer.NumberField = 20; 
    int publicField = valueContainer.NumberField; 
    } 
} 

आप EmbeddedTest.TestEmbeddedValues ​​()

.method public hidebysig instance void TestEmbeddedValues() cil managed 
{ 
    // Code size  23 (0x17) 
    .maxstack 2 
    .locals init ([0] class soapextensions.EmbeddedValues valueContainer, 
      [1] int32 publicField) 
    IL_0000: nop 
    IL_0001: newobj  instance void soapextensions.EmbeddedValues::.ctor() 
    IL_0006: stloc.0 
    IL_0007: ldloc.0 
    IL_0008: ldc.i4.s 20 
    IL_000a: stfld  int32 soapextensions.EmbeddedValues::NumberField 
    IL_000f: ldloc.0 
    IL_0010: ldfld  int32 soapextensions.EmbeddedValues::NumberField 
    IL_0015: stloc.1 
    IL_0016: ret 
} // end of method EmbeddedTest::TestEmbeddedValues 

सूचना CLR stfld करने के लिए कहा जा रहा है के लिए आईएल कोड में झांक सकते करने के लिए .NET फ्रेमवर्क एसडीके द्वारा प्रदान की MSIL Disassembler का उपयोग करते हैं लोड किए गए एम्बेडडवैल्यूज़ 'नंबर फ़ील्ड फ़ील्ड स्थान पर सीधे ढेर में "20" का भारित मूल्य, सीधे प्रबंधित ढेर में। इसी प्रकार, मान को पुनर्प्राप्त करते समय, यह ldfld निर्देश का उपयोग करता है ताकि सीधे प्रबंधित ढेर स्थान के थ्रेड स्टैक में मान को कॉपी किया जा सके। इन प्रकार के संचालन के साथ कोई बॉक्स/अनबॉक्सिंग नहीं होती है।

Answer 2

1. किसी भी संदर्भ या मूल्य प्रकार है कि एक वस्तु ढेर में रहते हैं के मालिक हैं।
2. केवल अगर आप ऑब्जेक्ट्स में इन्ट्स कास्टिंग कर रहे हैं।

Answer 3

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

Answer 4

स्टैक्स या ढेर पर रहने वाले ऑब्जेक्ट्स के भीतर मूल्य प्रकार करें?

ढेर पर।वे ऑब्जेक्ट के पदचिह्न के आवंटन का हिस्सा हैं, जैसे पॉइंटर्स संदर्भ धारण करना चाहते हैं।

किसी ऑब्जेक्ट में मुक्केबाजी/अनबॉक्सिंग मान प्रकार किसी चिंता का विषय है?

यहां कोई मुक्केबाजी नहीं है।

क्या इस विषय पर कोई विस्तृत, अभी तक समझने योग्य संसाधन हैं?

रिचटर की पुस्तक के लिए +1 वोट।

Answer 5

• उत्तर # 1: हीप। उनकी उत्कृष्ट से टीका डॉन बॉक्स 'आवश्यक नेट खंड 1'

संदर्भ प्रकार (आरटी) हमेशा उदाहरणों कि ढेर पर आवंटित किए जाते हैं उपज। इसके विपरीत, मान प्रकार (वीटी) संदर्भ पर निर्भर हैं - यदि कोई स्थानीय var एक VT है, तो CLR स्टैक पर स्मृति आवंटित करता है। यदि कक्षा में कोई क्षेत्र वीटी का सदस्य होता है, तो सीएलआर ऑब्जेक्ट/प्रकार के लेआउट के हिस्से के रूप में उदाहरण के लिए स्मृति आवंटित करता है जिसमें फ़ील्ड घोषित किया जाता है।

• उत्तर # 2: नहीं मुक्केबाजी केवल घटित होता है जब आप एक वस्तु संदर्भ/इंटरफ़ेस सूचक के माध्यम से एक struct का उपयोग। obInstance.VT_typedfield बॉक्स नहीं होगा।

  आरटी चर के उस वस्तु का पता होता है जो इसका संदर्भ देता है। 2 आरटी var एक ही वस्तु को इंगित कर सकते हैं।इसके विपरीत, वीटी चर स्वयं उदाहरण हैं। सी # के माध्यम से डॉन बॉक्स की असेंशियल .net/जेफरी रिक्टर की CLR: 2 वीटी वर एक ही वस्तु (struct)

• उत्तर # 3 को इंगित नहीं कर सकते। हालांकि बाद में अधिक नेट संशोधन के लिए अद्यतन किया जा सकता

Answer 6

एक चर या एक संरचना प्रकार के अन्य भंडारण स्थान है कि प्रकार के सार्वजनिक और निजी क्षेत्रों के उदाहरण के एकीकरण का है मैं पूर्व की एक प्रति है ...। यह देखते हुए

struct Foo {public int x,y; int z;} 

एक घोषणा Foo bar; कारण होगा जहाँ भी bar संग्रहित किया जा रहा है bar.x, bar.y, और bar.z संग्रहीत करने के लिए। एक कक्षा में bar की इस तरह की एक घोषणा को एक स्टोरेज-लेआउट परिप्रेक्ष्य से, तीन int फ़ील्ड जोड़ने के बराबर होगा। वास्तव में, अगर एक कभी नहीं पहुँच को छोड़कर bar के साथ कुछ भी किया है अपने खेतों, bar के क्षेत्र में एक ही होगा तीन क्षेत्रों bar_x, bar_y, और bar_cantaccessthis_z [पिछले एक तक पहुँचने के रूप में व्यवहार bar अपने क्षेत्रों तक पहुँचने के अलावा अन्य के साथ काम करने की आवश्यकता होगी होगा, लेकिन यह अंतरिक्ष ले जाएगा चाहे वह वास्तव में किसी भी चीज़ के लिए उपयोग किया जाता है]।

संरचनाओं को समझने के लिए पहला कदम है संरचनाओं के प्रकार के रूप में संरचना-प्रकार भंडारण स्थानों को पहचानना। उन्हें किसी प्रकार की वस्तु रखने के रूप में देखने की कोशिश करना "सरल" लग सकता है, लेकिन यह वास्तव में काम नहीं करता है।