.NET संदर्भ प्रकार बनाम मान प्रकार। भाग २

ऑब्जेक्ट आधार प्रकार और इंटरफेस का कार्यान्वयन। मुक्केबाज़ी

ऐसा लगता है कि हम नरक और उच्च पानी के माध्यम से आए हैं और किसी भी साक्षात्कार को नाखून कर सकते हैं, यहां तक ​​कि .NET सीएलआर टीम के लिए भी। हालाँकि, microsoft.com पर नहीं जाएँ और रिक्तियों की खोज करें। अब, हमें यह समझने की आवश्यकता है कि किसी ऑब्जेक्ट को कैसे इनहेरिट किया जाए, यदि उनके पास सिंकबॉकइंडेक्स का संदर्भ नहीं है, न कि किसी वर्चुअल मेथड टेबल का पॉइंटर। यह पूरी तरह से हमारे प्रकार की प्रणाली की व्याख्या करेगा और एक पहेली के सभी टुकड़ों को उनके स्थान मिलेंगे। हालाँकि, हमें एक से अधिक वाक्यों की आवश्यकता होगी।

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

यह इस विचार को ला सकता है कि विरासत की कमी कृत्रिम है

यह अध्याय रूसी से संयुक्त रूप से लेखक द्वारा और पेशेवर अनुवादकों द्वारा अनुवादित किया गया था । आप रूसी या अंग्रेजी से किसी अन्य भाषा में अनुवाद करने में हमारी मदद कर सकते हैं, मुख्यतः चीनी या जर्मन में।

इसके अलावा, अगर आप हमें धन्यवाद देना चाहते हैं, तो आप सबसे अच्छा तरीका यह कर सकते हैं कि हमें गितुब पर एक स्टार देना है या रिपॉजिटरी को फोर्क करना है github / sidristij / dotnetbook ।

यह विचार ला सकता है कि विरासत की कमी कृत्रिम है:

• एक वस्तु से विरासत है, लेकिन प्रत्यक्ष नहीं;
• आधार प्रकार के अंदर ToString, बराबरी और GetHashCode हैं। मूल्य प्रकारों में इन विधियों का अपना व्यवहार होता है। इसका मतलब है, कि किसी object संबंध में विधियां ओवरराइड हैं;
• इसके अलावा, यदि आप किसी object को टाइप करते हैं, तो आपको ToString, बराबरी और GetHashCode को कॉल करने का पूरा अधिकार है;
• जब एक मूल्य प्रकार के लिए एक इंस्टेंस विधि को कॉल करते हैं, तो विधि को एक और संरचना मिलती है जो एक मूल की एक प्रति है। इसका मतलब है कि एक इंस्टेंस मेथड कॉल करना स्टैटिक मेथड को कॉल करने जैसा है: Method(ref structInstance, newInternalFieldValue) । हालाँकि, यह कॉल एक अपवाद के साथ, इसे पास करता है। एक जेआईटी को एक विधि के शरीर को संकलित करना चाहिए, इसलिए यह संरचना क्षेत्रों को ऑफसेट करने के लिए अनावश्यक होगा, पॉइंटर पर एक आभासी तरीकों की मेज पर कूदना होगा, जो संरचना में मौजूद नहीं है। यह एक अन्य स्थान पर मूल्य प्रकारों के लिए मौजूद है ।

व्यवहार में प्रकार भिन्न हैं, लेकिन यह अंतर CLR में कार्यान्वयन के स्तर पर इतना बड़ा नहीं है। हम इसके बारे में थोड़ी देर बाद बात करेंगे।

हमारे कार्यक्रम में निम्नलिखित पंक्ति लिखें:

 var obj = (object)10; 

यह हमें बेस क्लास का उपयोग करके नंबर 10 से निपटने की अनुमति देगा। इसे बॉक्सिंग कहा जाता है। इसका मतलब है कि हमारे पास ऐसे वर्चुअल तरीकों को कॉल करने के लिए VMT है जैसे कि ToString (), बराबरी और GetHashCode। हकीकत में मुक्केबाजी एक मूल्य प्रकार की एक प्रति बनाता है, लेकिन एक मूल के लिए सूचक नहीं। ऐसा इसलिए है क्योंकि हम मूल मूल्य को हर जगह संग्रहीत कर सकते हैं: स्टैक पर या एक वर्ग के क्षेत्र के रूप में। यदि हम इसे एक ऑब्जेक्ट प्रकार पर रखते हैं, तो हम इस मान को एक संदर्भ स्टोर कर सकते हैं जब तक हम चाहते हैं। जब मुक्केबाजी होती है:

• सीएलआर एक संरचना के लिए ढेर पर जगह आवंटित करता है + एक मूल्य प्रकार के SyncBlockIndex + VMT (ToString, GetHashCode, बराबर) को कॉल करने के लिए;
• यह वहाँ एक मूल्य प्रकार के उदाहरण की प्रतिलिपि बनाता है।

अब, हमें मान प्रकार का एक संदर्भ संस्करण मिला है। एक संरचना को संदर्भ प्रकार के रूप में सिस्टम फ़ील्ड का बिल्कुल समान सेट मिला है,
मुक्केबाजी के बाद एक पूर्ण विकसित संदर्भ प्रकार बन गया। संरचना एक वर्ग बन गई। चलो इसे एक .NET somersault कहते हैं। यह एक उचित नाम है।

जरा देखें कि क्या होता है यदि आप एक संरचना का उपयोग करते हैं जो समान इंटरफ़ेस का उपयोग करके एक इंटरफ़ेस को लागू करता है।

 struct Foo : IBoo { int x; void Boo() { x = 666; } } IBoo boo = new Foo(); boo.Boo(); 

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

 IBoo boo = (IBoo)(box_to_object)new Foo(); boo.Boo(); 

ऐसे कोड लिखना प्रभावी नहीं है। आपको एक मूल के बजाय एक प्रति बदलनी होगी:

 void Main() { var foo = new Foo(); foo.a = 1; Console.WriteLite(foo.a); // -> 1 IBoo boo = foo; boo.Boo(); // looks like changing foo.a to 10 Console.WriteLite(foo.a); // -> 1 } struct Foo: IBoo { public int a; public void Boo() { a = 10; } } interface IBoo { void Boo(); } 

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

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

आप आपत्ति कर सकते हैं कि अगर यह सच था, तो यह इस तरह दिखाई देगा:

 var referenceToInteger = (IInt32)10; 

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

 public sealed class Boxed<T> { public T Value; [MethodImpl(MethodImplOptions.AggressiveInlining)] public override bool Equals(object obj) { return Value.Equals(obj); } [MethodImpl(MethodImplOptions.AggressiveInlining)] public override string ToString() { return Value.ToString(); } [MethodImpl(MethodImplOptions.AggressiveInlining)] public override int GetHashCode() { return Value.GetHashCode(); } } 

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

 var typedBoxing = new Boxed<int> { Value = 10 }; var pureBoxing = (object)10; 

पहला संस्करण बहुत आकर्षक नहीं है। एक प्रकार की कास्टिंग के बजाय हम बकवास बनाते हैं। दूसरी पंक्ति बहुत बेहतर है, लेकिन दो लाइनें लगभग समान हैं। अंतर केवल इतना है कि ढेर पर मेमोरी आवंटित करने के बाद सामान्य बॉक्सिंग के दौरान शून्य के साथ कोई मेमोरी सफाई नहीं होती है। आवश्यक संरचना स्मृति को सीधे ले जाती है जबकि पहले संस्करण को सफाई की आवश्यकता होती है। यह सामान्य बॉक्सिंग की तुलना में 10% अधिक लंबे समय तक काम करता है।

इसके बजाय, हम अपने बॉक्सिंग मूल्य के लिए कुछ तरीके कह सकते हैं।

 struct Foo { public int x; public void ChangeTo(int newx) { x = newx; } } var boxed = new Boxed<Foo> { Value = new Foo { x = 5 } }; boxed.Value.ChangeTo(10); var unboxed = boxed.Value; 

हमें एक नया उपकरण मिला है। आइए सोचते हैं कि हम इसके साथ क्या कर सकते हैं।

• हमारा Boxed<T> प्रकार सामान्य प्रकार के समान है: ढेर पर मेमोरी आवंटित करता है, वहां एक मान गुजरता है और एक प्रकार का अनबॉक्स करके, इसे प्राप्त करने की अनुमति देता है;
• यदि आप एक बॉक्सिंग संरचना का संदर्भ खो देते हैं, तो जीसी इसे इकट्ठा करेगा;
• हालाँकि, अब हम एक बॉक्सिंग प्रकार के साथ काम कर सकते हैं, अर्थात इसके तरीकों को बुला सकते हैं;
• इसके अलावा, हम SOH / LOH में एक दूसरे के लिए एक वैल्यू टाइप का उदाहरण बदल सकते हैं। हम पहले ऐसा नहीं कर सकते थे, क्योंकि हमें अनबॉक्सिंग करना होगा, संरचना को दूसरे में बदलना होगा और बॉक्सिंग करना होगा, जिससे ग्राहकों को एक नया संदर्भ मिलेगा।

मुक्केबाजी की मुख्य समस्या स्मृति में यातायात पैदा करना है। वस्तुओं की अज्ञात संख्या का ट्रैफ़िक, जिसका एक भाग पीढ़ी दर पीढ़ी तक जीवित रह सकता है, जहाँ हमें कचरा संग्रहण की समस्या आती है। बहुत सारा कचरा होगा और हम इससे बच सकते थे। लेकिन जब हमारे पास अल्पकालिक वस्तुओं का आवागमन होता है, तो पहला उपाय पूलिंग होता है। यह .NET somersault का एक आदर्श अंत है।

 var pool = new Pool<Boxed<Foo>>(maxCount:1000); var boxed = pool.Box(10); boxed.Value=70; // use boxed value here pool.Free(boxed); 

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

आइए निष्कर्ष निकालते हैं:

• यदि बॉक्सिंग आकस्मिक है और ऐसा नहीं होना चाहिए, तो ऐसा न करें। यह प्रदर्शन के साथ समस्याओं को जन्म दे सकता है।
• यदि किसी सिस्टम की वास्तुकला के लिए बॉक्सिंग आवश्यक है, तो वेरिएंट हो सकते हैं। यदि बॉक्सिंग संरचनाओं का ट्रैफ़िक छोटा और लगभग अदृश्य है, तो आप बॉक्सिंग का उपयोग कर सकते हैं। यदि ट्रैफ़िक दिखाई देता है, तो आप ऊपर बताए गए किसी एक समाधान का उपयोग करके, बॉक्सिंग की पूलिंग करना चाह सकते हैं। यह कुछ संसाधनों को खर्च करता है, लेकिन बिना अधिभार के जीसी कार्य करता है;

अंततः एक पूरी तरह से अव्यावहारिक कोड को देखें:

 static unsafe void Main() { // here we create boxed int object boxed = 10; // here we get the address of a pointer to a VMT var address = (void**)EntityPtr.ToPointerWithOffset(boxed); unsafe { // here we get a Virtual Methods Table address var structVmt = typeof(SimpleIntHolder).TypeHandle.Value.ToPointer(); // change the VMT address of the integer passed to Heap into a VMT SimpleIntHolder, turning Int into a structure *address = structVmt; } var structure = (IGetterByInterface)boxed; Console.WriteLine(structure.GetByInterface()); } interface IGetterByInterface { int GetByInterface(); } struct SimpleIntHolder : IGetterByInterface { public int value; int IGetterByInterface.GetByInterface() { return value; } } 

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

1. पूर्णांक के लिए बॉक्सिंग करें।
2. प्राप्त वस्तु का पता प्राप्त करें (Int32 VMT का पता)
3. एक SimpleIntHolder का VMT प्राप्त करें
4. एक संरचना के VMT के लिए एक बॉक्सिंग पूर्णांक के VMT को बदलें।
5. संरचना प्रकार में अनबॉक्सिंग करें
6. स्क्रीन पर फ़ील्ड मान प्रदर्शित करें, जो इंट 32 प्राप्त कर रहा था
   बॉक्सिंग।

मैं इसे इंटरफेस पर उद्देश्य से करता हूं क्योंकि मैं यह दिखाना चाहता हूं कि यह काम करेगा
इस तरह।

अशक्त \ _ <टी>

यह अशक्त मूल्य प्रकारों के साथ मुक्केबाजी के व्यवहार के बारे में ध्यान देने योग्य है। Nullable value type की यह सुविधा बहुत ही आकर्षक है क्योंकि एक वैल्यू टाइप का बॉक्सिंग जो एक प्रकार का अशक्त रिटर्न null है।

 int? x = 5; int? y = null; var boxedX = (object)x; // -> 5 var boxedY = (object)y; // -> null 

यह हमें एक अजीब निष्कर्ष पर ले जाता है: क्योंकि अशक्त में एक प्रकार नहीं है, एक
केवल एक प्रकार पाने के लिए, बॉक्सिंग से अलग एक निम्नलिखित है:

 int? x = null; var pseudoBoxed = (object)x; double? y = (double?)pseudoBoxed; 

कोड सिर्फ इसलिए काम करता है क्योंकि आप किसी भी प्रकार को अपनी पसंद के अनुसार रख सकते हैं
अशक्त के साथ।

बॉक्सिंग में गहराई तक जा रहे हैं

अंतिम बिट के रूप में, मैं आपको System.Enum प्रकार के बारे में बताना चाहूंगा। तार्किक रूप से यह एक मूल्य प्रकार होना चाहिए क्योंकि यह एक सामान्य ज्ञान है: प्रोग्रामिंग भाषा में नाम के लिए संख्याओं का उपनाम। हालाँकि, System.Enum एक संदर्भ प्रकार है। आपके क्षेत्र के साथ-साथ .NET फ्रेमवर्क में परिभाषित सभी Enum डेटा प्रकार, System.Enum से विरासत में मिले हैं। यह एक वर्ग डेटा प्रकार है। इसके अलावा, यह एक अमूर्त वर्ग है, जिसे System.ValueType से विरासत में मिला है।

  [Serializable] [System.Runtime.InteropServices.ComVisible(true)] public abstract class Enum : ValueType, IComparable, IFormattable, IConvertible { // ... } 

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

सच्चाई यह है कि सीएलआर डेटा प्रकार की संरचना को हैक करता है, अगर इसे बनाने के लिए एक मान है जो किसी वर्ग को मान प्रकार में बदल रहा है :

 // Check to see if the class is a valuetype; but we don't want to mark System.Enum // as a ValueType. To accomplish this, the check takes advantage of the fact // that System.ValueType and System.Enum are loaded one immediately after the // other in that order, and so if the parent MethodTable is System.ValueType and // the System.Enum MethodTable is unset, then we must be building System.Enum and // so we don't mark it as a ValueType. if(HasParent() && ((g_pEnumClass != NULL && GetParentMethodTable() == g_pValueTypeClass) || GetParentMethodTable() == g_pEnumClass)) { bmtProp->fIsValueClass = true; HRESULT hr = GetMDImport()->GetCustomAttributeByName(bmtInternal->pType->GetTypeDefToken(), g_CompilerServicesUnsafeValueTypeAttribute, NULL, NULL); IfFailThrow(hr); if (hr == S_OK) { SetUnsafeValueClass(); } } 

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

यदि आप व्यक्तिगत रूप से मुक्केबाजी देखना चाहते हैं तो क्या होगा?

सौभाग्य से, आपको एक disassembler का उपयोग करने और कोड जंगल में जाने की आवश्यकता नहीं है। हमारे पास पूरे .NET प्लेटफ़ॉर्म कोर के पाठ हैं और उनमें से कई .NET फ्रेमवर्क CLR और CoreCLR के संदर्भ में समान हैं। आप नीचे दिए गए लिंक पर क्लिक कर सकते हैं और तुरंत बॉक्सिंग के कार्यान्वयन को देख सकते हैं:

• अनुकूलन का एक अलग समूह है, जिसमें से प्रत्येक का उपयोग करता है
  प्रोसेसर का विशिष्ट प्रकार:
  
  • JIT_BoxFastMP_InlineGetThread
    (AMD64 - मल्टीप्रोसेसर या सर्वर जीसी, अंतर्निहित थ्रेड लोकल स्टोरेज)
  • JIT_BoxFastMP
    (एएमडी ६४ - मल्टीप्रोसेसर या सर्वर जीसी)
  • JIT_BoxFastUP
    (AMD64 - सिंगल प्रोसेसर या वर्कस्टेशन GC)
  • JIT_TrialAlloc :: जेनबॉक्स (..)
    (x86) जीथेलपर्स के माध्यम से जुड़ा हुआ है
• सामान्य मामलों में एक जेआईटी एक हेल्पर फंक्शन की कॉल को बताता है
  कंपाइलर :: impImportAndPushBox (..)
• सामान्य-संस्करण कम अनुकूलित का उपयोग करता है
  MethodTable :: बॉक्स (..)
  
  • अंत में, [CopyValueClassUnchecked (..)] कहा जाता है
    ( https://github.com/dotnet/coreclr/blob/master/src/vm/object.cpp#L1514-L1581 )।
    इसके कोड से पता चलता है कि 8 बाइट वाले आकार के साथ संरचनाओं को चुनना बेहतर क्यों है।

यहाँ, एकमात्र विधि का उपयोग अनबॉक्सिंग के लिए किया जाता है:
JIT_Unbox (..) , जो JIT_Unbox_Helper (..) के आसपास एक आवरण है।

यह भी दिलचस्प है कि ( https://stackoverflow.com/questions/3743762/unboxing-does-not-create-a-copy-of-the-value-is-this-right ), नकल का मतलब नकल नहीं है ढेर करने के लिए डेटा। बॉक्सिंग का अर्थ है कि प्रकारों की अनुकूलता का परीक्षण करते समय एक सूचक को ढेर तक पहुंचाना। अनबॉक्सिंग के बाद IL opcode इस पते के साथ क्रियाओं को परिभाषित करेगा। किसी विधि को कॉल करने के लिए डेटा को स्थानीय चर या स्टैक में कॉपी किया जा सकता है। अन्यथा, हमारे पास दोहरी प्रतिलिपि होगी; पहली बार जब कहीं से ढेर की नकल कर रहा है, और फिर गंतव्य स्थान पर कॉपी कर रहा है।

प्रश्न

क्यों .NET CLR खुद मुक्केबाजी के लिए पूलिंग नहीं कर सकता है?

अगर हम किसी जावा डेवलपर से बात करते हैं, तो हम दो बातें जानेंगे:

• जावा में सभी मूल्य प्रकार बॉक्सिंग हैं, जिसका अर्थ है कि वे अनिवार्य रूप से मूल्य प्रकार नहीं हैं। इंटेगर भी बॉक्सिंग कर रहे हैं।
• अनुकूलन के कारण के लिए -128 से 127 तक के सभी पूर्णांक वस्तुओं के पूल से लिए गए हैं।

तो, बॉक्सिंग के दौरान .NET CLR में ऐसा क्यों नहीं होता है? यह सरल है। क्योंकि हम एक बॉक्सिंग मूल्य प्रकार की सामग्री को बदल सकते हैं, अर्थात हम निम्नलिखित कर सकते हैं:

 object x = 1; x.GetType().GetField("m_value", BindingFlags.Instance | BindingFlags.NonPublic).SetValue(x, 138); Console.WriteLine(x); // -> 138 

या इस तरह (C ++ / CLI):

 void ChangeValue(Object^ obj) { Int32^ i = (Int32^)obj; *i = 138; } 

यदि हम पूलिंग से निपटते हैं, तो हम सभी को एप्लीकेशन में बदलकर 138 कर देंगे, जो अच्छा नहीं है।

अगला .NET में मूल्य प्रकारों का सार है। वे मूल्य के साथ सौदा करते हैं, जिसका अर्थ है कि वे तेजी से काम करते हैं। मुक्केबाजी दुर्लभ है और बॉक्सिंग संख्याओं के अलावा कल्पना और बुरी वास्तुकला की दुनिया से संबंधित है। यह बिलकुल भी उपयोगी नहीं है।

ढेर के बजाय स्टैक पर बॉक्सिंग करना क्यों संभव नहीं है, जब आप एक विधि प्रकार कहते हैं जो एक वस्तु प्रकार लेता है, जो वास्तव में एक मूल्य प्रकार है?

यदि स्टैक पर मान प्रकार बॉक्सिंग किया जाता है और संदर्भ ढेर पर जाएगा, तो विधि के अंदर संदर्भ कहीं और जा सकता है, उदाहरण के लिए एक विधि संदर्भ को एक वर्ग के क्षेत्र में रख सकती है। विधि तब बंद हो जाएगी, और बॉक्सिंग करने वाली विधि भी बंद हो जाएगी। नतीजतन, संदर्भ स्टैक पर एक मृत स्थान को इंगित करेगा।

फ़ील्ड के रूप में मान प्रकार का उपयोग करना क्यों संभव नहीं है?

कभी-कभी हम किसी अन्य संरचना के क्षेत्र के रूप में एक संरचना का उपयोग करना चाहते हैं जो पहले का उपयोग करता है। या सरल: एक संरचना क्षेत्र के रूप में संरचना का उपयोग करें। मुझसे मत पूछो कि यह क्यों उपयोगी हो सकता है। यह नहीं कर सकता। यदि आप किसी संरचना को उसके क्षेत्र के रूप में या किसी अन्य संरचना के साथ निर्भरता के माध्यम से उपयोग करते हैं, तो आप पुनरावर्तन बनाते हैं, जिसका अर्थ है अनंत आकार की संरचना। हालाँकि, .NET फ्रेमवर्क में कुछ स्थान हैं जहाँ आप इसे कर सकते हैं। एक उदाहरण System.Char , जिसमें स्वयं शामिल हैं :

 public struct Char : IComparable, IConvertible { // Member Variables internal char m_value; //... } 

सभी सीएलआर आदिम प्रकार इस तरह से डिज़ाइन किए गए हैं। हम, केवल नश्वर, इस व्यवहार को लागू नहीं कर सकते। इसके अलावा, हमें इसकी आवश्यकता नहीं है: यह सीएलआर में आदिम प्रकार की भावना को देने के लिए किया जाता है।

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

इसके अलावा, यदि आप "धन्यवाद" कहना चाहते हैं, तो सबसे अच्छा तरीका जो आप चुन सकते हैं, वह हमें जीथब या रिपॉजिटरी पर एक स्टार दे रहा है। https://github.com/sidristij/dotnetbook