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

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

आइए वास्तविक अंतरों पर चर्चा करें:

• एक मान प्रकार : इसका मान संपूर्ण संरचना है । संदर्भ प्रकार का मान किसी वस्तु का संदर्भ होता है। - स्मृति में एक संरचना: मूल्य प्रकार में केवल आपके द्वारा संकेतित डेटा होता है। संदर्भ प्रकारों में दो सिस्टम फ़ील्ड भी होते हैं। पहला एक 'SyncBlockIndex' स्टोर करता है, दूसरा एक प्रकार के बारे में जानकारी संग्रहीत करता है, जिसमें वर्चुअल मेथड्स टेबल (VMT) के बारे में जानकारी शामिल है।
• संदर्भ प्रकार में ऐसे तरीके हो सकते हैं जो विरासत में मिलने पर ओवरराइड हो जाते हैं। मूल्य प्रकार विरासत में नहीं मिल सकते हैं।
• आपको संदर्भ प्रकार के उदाहरण के लिए ढेर पर जगह आवंटित करनी चाहिए। स्टैक पर एक मान प्रकार आवंटित किया जा सकता है, या यह एक संदर्भ प्रकार का हिस्सा बन जाता है। यह कुछ एल्गोरिदम के प्रदर्शन को पर्याप्त रूप से बढ़ाता है।

हालाँकि, आम विशेषताएं हैं:

• दोनों उपवर्ग वस्तु प्रकार को विरासत में ले सकते हैं और इसके प्रतिनिधि बन सकते हैं।

आइए प्रत्येक सुविधा को करीब से देखें।

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

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

आइए प्रत्येक सुविधा को करीब से देखें।

प्रतिलिपि बनाई जा रही

दो प्रकारों के बीच मुख्य अंतर इस प्रकार है:

• प्रत्येक चर, वर्ग या संरचना क्षेत्र या विधि पैरामीटर जो एक संदर्भ प्रकार को एक मूल्य के संदर्भ में स्टोर करते हैं ;
• लेकिन प्रत्येक चर, वर्ग या संरचना क्षेत्र या विधि पैरामीटर जो मान प्रकार लेते हैं एक मूल्य बिल्कुल, अर्थात एक पूरी संरचना को स्टोर करते हैं।

इसका मतलब यह है कि किसी पैरामीटर को किसी विधि से असाइन करना या पास करना मान को कॉपी करेगा। यदि आप कॉपी बदलते हैं, तो भी मूल वही रहेगा। हालाँकि, यदि आप संदर्भ प्रकार फ़ील्ड बदलते हैं, तो यह एक प्रकार के उदाहरण के संदर्भ में सभी भागों को "प्रभावित" करेगा। आइए नजर डालते हैं
उदाहरण:

DateTime dt = DateTime.Now; // Here, we allocate space for DateTime variable when calling a method, // but it will contain zeros. Next, let's copy all // values of the Now property to dt variable DateTime dt2 = dt; // Here, we copy the value once again object obj = new object(); // Here, we create an object by allocating memory on the Small Object Heap, // and put a pointer to the object in obj variable object obj2 = obj; // Here, we copy a reference to this object. Finally, // we have one object and two references. 

ऐसा लगता है कि यह संपत्ति अस्पष्ट कोड निर्माण का उत्पादन करती है जैसे कि
संग्रह में कोड का परिवर्तन:

 // Let's declare a structure struct ValueHolder { public int Data; } // Let's create an array of such structures and initialize the Data field = 5 var array = new [] { new ValueHolder { Data = 5 } }; // Let's use an index to get the structure and put 4 in the Data field array[0].Data = 4; // Let's check the value Console.WriteLine(array[0].Data); 

इस कोड में एक छोटी सी ट्रिक है। ऐसा लगता है कि हमें पहले संरचना उदाहरण मिलता है, और फिर प्रतिलिपि के डेटा फ़ील्ड में एक नया मान असाइन किया जाता है। इसका मतलब है कि मूल्य की जांच करते समय हमें फिर से 5 प्राप्त करना चाहिए। हालाँकि, ऐसा नहीं होता है। MSIL के पास एक सरणी की संरचनाओं में फ़ील्ड के मूल्यों को सेट करने के लिए एक अलग निर्देश है, जो प्रदर्शन को बढ़ाता है। कोड इरादा के रूप में काम करेगा: कार्यक्रम होगा
कंसोल के लिए आउटपुट 4 ।

आइए देखते हैं कि इस कोड को बदलने पर क्या होगा:

 // Let's declare a structure struct ValueHolder { public int Data; } // Let's create a list of such structures and initialize the Data field = 5 var list = new List<ValueHolder> { new ValueHolder { Data = 5 } }; // Let's use an index to get the structure and put 4 in the Data field list[0].Data = 4; // Let's check the value Console.WriteLine(list[0].Data); 

इस कोड का संकलन विफल हो जाएगा, क्योंकि जब आप list[0].Data = 4 लिखते हैं list[0].Data = 4 आपको पहले संरचना की प्रतिलिपि मिलती है। वास्तव में, आप List<T> प्रकार की एक आवृत्ति विधि को कॉल कर रहे हैं जो एक अनुक्रमणिका द्वारा पहुंच को कम करती है। यह आंतरिक सरणी से एक संरचना की प्रतिलिपि लेता है ( List<T> सरणियों में डेटा संग्रहीत करता है) और एक अनुक्रमणिका का उपयोग करके आपको इस प्रति को एक्सेस विधि से वापस करता है। अगला, आप प्रतिलिपि को संशोधित करने का प्रयास करते हैं, जिसका उपयोग आगे नहीं किया जाता है। यह कोड व्यर्थ है। एक कंपाइलर इस तरह के व्यवहार को प्रतिबंधित करता है, यह जानकर कि लोग मूल्य प्रकार का दुरुपयोग करते हैं। हमें इस उदाहरण को निम्नलिखित तरीके से लिखना चाहिए:

 // Let's declare a structure struct ValueHolder { public int Data; } // Let's create a list of such structures and initialize the Data field = 5 var list = new List<ValueHolder> { new ValueHolder { Data = 5 } }; // Let's use an index to get the structure and put 4 in the Data field. Then, let's save it again. var copy = list[0]; copy.Data = 4; list[0] = copy; // Let's check the value Console.WriteLine(list[0].Data); 

यह कोड इसके स्पष्ट अतिरेक के बावजूद सही है। कार्यक्रम होगा
कंसोल के लिए आउटपुट 4 ।

अगले उदाहरण से पता चलता है कि "एक संरचना का मूल्य" क्या है
पूरी संरचना ”

 // Variant 1 struct PersonInfo { public int Height; public int Width; public int HairColor; } int x = 5; PersonInfo person; int y = 6; // Variant 2 int x = 5; int Height; int Width; int HairColor; int y = 6; 

दोनों उदाहरण स्मृति में डेटा स्थान के संदर्भ में समान हैं, क्योंकि संरचना का मूल्य संपूर्ण संरचना है। यह अपने लिए मेमोरी आवंटित करता है जहां यह है।

 // Variant 1 struct PersonInfo { public int Height; public int Width; public int HairColor; } class Employee { public int x; public PersonInfo person; public int y; } // Variant 2 class Employee { public int x; public int Height; public int Width; public int HairColor; public int y; } 

ये उदाहरण भी स्मृति में तत्वों के स्थान के संदर्भ में समान हैं क्योंकि संरचना वर्गीय क्षेत्रों के बीच परिभाषित स्थान लेती है। मैं नहीं कहता कि वे पूरी तरह से समान हैं क्योंकि आप संरचना के तरीकों का उपयोग करके संरचना क्षेत्रों को संचालित कर सकते हैं।

बेशक, यह संदर्भ प्रकारों का मामला नहीं है। एक उदाहरण अपने आप में अनुपलब्ध स्मॉल ऑब्जेक्ट हीप (SOH) या लार्ज ऑब्जेक्ट हीप (LOH) पर है। एक वर्ग फ़ील्ड में केवल सूचक का मान होता है उदाहरण के लिए: 32 या 64-बिट संख्या।

आइए मुद्दे को बंद करने के लिए अंतिम उदाहरण देखें।

 // Variant 1 struct PersonInfo { public int Height; public int Width; public int HairColor; } void Method(int x, PersonInfo person, int y); // Variant 2 void Method(int x, int HairColor, int Width, int Height, int y); 

स्मृति के संदर्भ में कोड के दोनों प्रकार समान रूप से काम करेंगे, लेकिन वास्तुकला के संदर्भ में नहीं। यह केवल तर्कों की परिवर्तनशील संख्या का प्रतिस्थापन नहीं है। क्रम बदलता है क्योंकि विधि पैरामीटर एक के बाद एक घोषित किए जाते हैं। उन्हें उसी तरह स्टैक पर रखा जाता है।

हालाँकि, स्टैक उच्च से निम्न पते तक बढ़ता है। इसका मतलब है कि एक संरचना के टुकड़े को टुकड़े से धकेलने का क्रम इसे एक पूरे के रूप में धकेलने से अलग होगा।

ओवररिएड करने के तरीके और विरासत

दो प्रकारों के बीच अगला बड़ा अंतर आभासी की कमी है
विधियों में तालिकाएँ। इसका मतलब है कि:

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

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

आइए दिखाते हैं कि यह अतिरिक्त तर्क के बिना सिर्फ एक मेमोरी रेंज है।

 unsafe void Main() { int secret = 666; HeightHolder hh; hh.Height = 5; WidthHolder wh; unsafe { // This cast wouldn't work if structures had the information about a type. // The CLR would check a hierarchy before casting a type and if it didn't find WidthHolder, // it would output an InvalidCastException exception. But since a structure is a memory range, // you can interpret it as any kind of structure. wh = *(WidthHolder*)&hh; } Console.WriteLine("Width: " + wh.Width); Console.WriteLine("Secret:" + wh.Secret); } struct WidthHolder { public int Width; public int Secret; } struct HeightHolder { public int Height; } 

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

आवृत्ति विधियों को कॉल करते समय व्यवहार

दोनों डेटा प्रकारों में एक और विशेषता है जो देखने के लिए सरल नहीं है और दोनों प्रकारों की संरचना की व्याख्या कर सकते हैं। यह कॉलिंग इंस्टेंस विधियों से संबंधित है।

 // The example with a reference type class FooClass { private int x; public void ChangeTo(int val) { x = val; } } // The example with a value type struct FooStruct { private int x; public void ChangeTo(int val) { x = val; } } FooClass klass = new FooClass(); FooStruct strukt = new FooStruct(); klass.ChangeTo(10); strukt.ChangeTo(10); 

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

 // An example with a reference type class FooClass { public int x; } // An example with a value type struct FooStruct { public int x; } public void ChangeTo(FooClass klass, int val) { klass.x = val; } public void ChangeTo(ref FooStruct strukt, int val) { strukt.x = val; } FooClass klass = new FooClass(); FooStruct strukt = new FooStruct(); ChangeTo(klass, 10); ChangeTo(ref strukt, 10); 

मुझे रेफरी कीवर्ड के उपयोग की व्याख्या करनी चाहिए। यदि मैंने इसका उपयोग नहीं किया, तो मुझे मूल के बजाय एक विधि पैरामीटर के रूप में संरचना की एक प्रति प्राप्त होगी। फिर मैं इसे बदल दूंगा, लेकिन मूल वही रहेगा। मुझे एक विधि से एक कॉलर (दूसरी प्रतिलिपि) में एक परिवर्तित प्रतिलिपि वापस करना होगा, और कॉलर इस मान को चर (एक और प्रतिलिपि) में वापस बचाएगा। इसके बजाय, एक इंस्टेंस मेथड एक पॉइंटर प्राप्त करता है और इसका उपयोग मूल को सीधे बदलने के लिए करता है। एक पॉइंटर का उपयोग प्रदर्शन को प्रभावित नहीं करता है क्योंकि कोई भी प्रोसेसर-स्तरीय ऑपरेशन पॉइंटर्स का उपयोग करता है। Ref, C # दुनिया का एक हिस्सा है, और नहीं।

तत्वों की स्थिति को इंगित करने की क्षमता।

दोनों संरचना और कक्षाएं स्मृति में एक संरचना की शुरुआत के संबंध में किसी विशेष क्षेत्र की ऑफसेट को इंगित करने की एक और क्षमता है। यह कई उद्देश्य प्रदान करता है:

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

सामान्य टिप्पणी

• ऑटो : रन-टाइम वातावरण स्वचालित रूप से सभी वर्ग या संरचना क्षेत्रों के लिए एक स्थान और एक पैकिंग चुनता है। इस गणना के एक सदस्य द्वारा चिह्नित परिभाषित संरचनाएं अप्रबंधित कोड में पारित नहीं हो सकती हैं। इसे करने का प्रयास एक अपवाद पैदा करेगा;
• स्पष्ट : एक प्रोग्रामर स्पष्ट रूप से FieldOffsetAttribute के साथ एक प्रकार के प्रत्येक क्षेत्र के सटीक स्थान को नियंत्रित करता है;
• अनुक्रमिक : प्रकार के सदस्य क्रमबद्ध क्रम में आते हैं, जो प्रकार के डिजाइन के दौरान परिभाषित होते हैं। StructLayoutAttribute.Pack एक पैकिंग कदम के मूल्य उनके स्थान को इंगित करता है।

अप्रयुक्त संरचना फ़ील्ड को छोड़ने के लिए FieldOffset का उपयोग करना

मानव रहित दुनिया से आने वाली संरचनाओं में आरक्षित क्षेत्र हो सकते हैं। एक पुस्तकालय के भविष्य के संस्करण में उनका उपयोग कर सकते हैं। C / C ++ में, हम फ़ील्ड जोड़कर इन अंतरालों को भरते हैं, जैसे आरक्षित 1, आरक्षित 2, ... हालाँकि, .NET में हम केवल FieldOffsetAttribute विशेषता और [StructLayout(LayoutKind.Explicit)] का उपयोग करके किसी फ़ील्ड की शुरुआत में ऑफसेट करते हैं।

 [StructLayout(LayoutKind.Explicit)] public struct SYSTEM_INFO { [FieldOffset(0)] public ulong OemId; // 92 bytes reserved [FieldOffset(100)] public ulong PageSize; [FieldOffset(108)] public ulong ActiveProcessorMask; [FieldOffset(116)] public ulong NumberOfProcessors; [FieldOffset(124)] public ulong ProcessorType; } 

एक अंतर पर कब्जा कर लिया गया लेकिन अप्रयुक्त स्थान है। संरचना का आकार 132 के बराबर होगा न कि 40 बाइट्स जैसा कि यह शुरुआत से लग सकता है।

संघ

FieldOffsetAttribute का उपयोग करके आप C / C ++ प्रकार का अनुकरण कर सकते हैं जिसे संघ कहा जाता है। यह उसी डेटा को एक्सेस करने की अनुमति देता है, जिसमें से निकाय हैं
विभिन्न प्रकार। आइए उदाहरण देखें:

 // If we read the RGBA.Value, we will get an Int32 value accumulating all // other fields. // However, if we try to read the RGBA.R, RGBA.G, RGBA.B, RGBA.Alpha, we // will get separate components of Int32. [StructLayout(LayoutKind.Explicit)] public struct RGBA { [FieldOffset(0)] public uint Value; [FieldOffset(0)] public byte R; [FieldOffset(1)] public byte G; [FieldOffset(2)] public byte B; [FieldOffset(3)] public byte Alpha; } 

आप कह सकते हैं कि इस तरह का व्यवहार केवल मूल्य प्रकारों के लिए संभव है। हालाँकि, आप इसे संदर्भ प्रकारों के लिए अनुकरण कर सकते हैं, दो संदर्भ प्रकारों को ओवरलैप करने के लिए एक पते का उपयोग करके या एक संदर्भ प्रकार और एक मान प्रकार:

 class Program { public static void Main() { Union x = new Union(); x.Reference.Value = "Hello!"; Console.WriteLine(x.Value.Value); } [StructLayout(LayoutKind.Explicit)] public class Union { public Union() { Value = new Holder<IntPtr>(); Reference = new Holder<object>(); } [FieldOffset(0)] public Holder<IntPtr> Value; [FieldOffset(0)] public Holder<object> Reference; } public class Holder<T> { public T Value; } } 

मैंने उद्देश्य पर अतिव्यापी के लिए एक सामान्य प्रकार का उपयोग किया। अगर मैं सामान्य इस्तेमाल करता
ओवरलैपिंग, अनुप्रयोग डोमेन में लोड होने पर यह प्रकार TypeLoadException का कारण होगा। यह सिद्धांत में सुरक्षा उल्लंघन की तरह लग सकता है (विशेषकर, जब एप्लिकेशन प्लग-इन के बारे में बात कर रहा है), लेकिन अगर हम एक संरक्षित डोमेन का उपयोग करके इस कोड को चलाने का प्रयास करते हैं, तो हमें एक ही प्रकार TypeLoadException ।

आवंटन में अंतर

एक अन्य विशेषता जो दोनों प्रकारों को अलग करती है वह है वस्तुओं या संरचनाओं के लिए स्मृति आवंटन। किसी ऑब्जेक्ट के लिए मेमोरी आवंटित करने से पहले CLR को कई चीजों पर निर्णय लेना चाहिए। किसी वस्तु का आकार क्या है? क्या यह 85K से अधिक या कम है? यदि यह कम है, तो क्या इस ऑब्जेक्ट को आवंटित करने के लिए SOH पर पर्याप्त खाली स्थान है? यदि यह अधिक है, सीएलआर कचरा संग्राहक को सक्रिय करता है। यह ऑब्जेक्ट ग्राफ के माध्यम से जाता है, ऑब्जेक्ट को क्लीयर किए गए स्थान पर ले जाकर कॉम्पैक्ट करता है। यदि एसओएच पर अभी भी जगह नहीं है, तो अतिरिक्त वर्चुअल मेमोरी पेज का आवंटन शुरू हो जाएगा। यह केवल तब होता है जब किसी वस्तु को कचरे से साफ किया गया स्थान आवंटित किया जाता है। बाद में, CLR SyncBlockIndex और VirtualMethodsTable को खो देता है। अंत में, एक वस्तु का संदर्भ एक उपयोगकर्ता को देता है।

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

RefTypes के लिए कई संभावित परिदृश्य हैं:

• RefType <85K, SOH पर स्थान है: त्वरित मेमोरी आवंटन;
• RefType <85K, SOH पर स्थान बाहर चल रहा है: बहुत धीमी मेमोरी आवंटन;
• RefType> 85K, धीमी मेमोरी आवंटन।

ऐसे ऑपरेशन दुर्लभ हैं और ValTypes के साथ प्रतिस्पर्धा नहीं कर सकते। मान प्रकार के लिए स्मृति आबंटन का एल्गोरिथ्म मौजूद नहीं है। मूल्य प्रकारों के लिए मेमोरी के आवंटन में कुछ भी खर्च नहीं होता है। केवल एक चीज जो इस प्रकार के लिए मेमोरी आवंटित करते समय होती है, वह फ़ील्ड को शून्य करने के लिए सेट कर रही है। आइए देखें कि ऐसा क्यों होता है: 1. जब कोई एक विधि के शरीर में एक चर घोषित करता है, तो एक संरचना के लिए स्मृति आवंटन का समय शून्य के करीब है। ऐसा इसलिए है क्योंकि स्थानीय चर के लिए आवंटन का समय उनकी संख्या पर निर्भर नहीं करता है; 2. यदि ValTypes को खेतों के रूप में आवंटित किया जाता है, तो Reftypes खेतों का आकार बढ़ा देगा। एक मान प्रकार पूरी तरह से आवंटित किया जाता है, इसका हिस्सा बन जाता है; 3. जैसा कि नकल के मामले में, यदि ValTypes को विधि मापदंडों के रूप में पारित किया जाता है, तो एक पैरामीटर के आकार और स्थान के आधार पर, एक अंतर दिखाई देता है।

हालाँकि, एक चर को दूसरे में कॉपी करने की तुलना में अधिक समय नहीं लगता है।

एक वर्ग या एक संरचना के बीच का चुनाव

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

• टाइप सिस्टम आर्किटेक्चर पर आधारित, जिसमें आपका प्रकार बातचीत करेगा;
• इष्टतम प्रदर्शन के साथ एक प्रकार चुनने के लिए सिस्टम प्रोग्रामर के रूप में आपके दृष्टिकोण के आधार पर;
• जब कोई दूसरा विकल्प न हो।

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

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

   
   
   • डेटटाइम एक संरचना है जो समय में एक पल की अवधारणा को घेर लेती है। यह इस डेटा को यूंट के रूप में संग्रहीत करता है, लेकिन समय, वर्ष, माह, दिन, घंटा, मिनट, सेकंड, मिलीसेकंड और यहां तक ​​कि प्रोसेसर टिक की अलग-अलग विशेषताओं तक पहुंच प्रदान करता है। हालांकि, यह अपरिवर्तनीय है, जो इसे एनकैप्सलेट करता है, उस पर आधारित है। हम समय में एक पल नहीं बदल सकते। मैं अगले मिनट नहीं जी सकता क्योंकि यह बचपन में मेरा सबसे अच्छा जन्मदिन था। इस प्रकार, यदि हम एक डेटा प्रकार चुनते हैं, तो हम एक कक्षा को आसानी से इंटरफ़ेस के साथ चुन सकते हैं, जो गुणों के प्रत्येक परिवर्तन के लिए एक नया उदाहरण प्रस्तुत करता है। या, हम एक संरचना चुन सकते हैं, जो अपने उदाहरणों के क्षेत्रों को बदल नहीं सकती है: इसका मूल्य एक समय की तरह, एक नंबर की तरह है। आप किसी संख्या की संरचना तक नहीं पहुँच सकते और इसे बदल सकते हैं। यदि आप समय में एक और क्षण प्राप्त करना चाहते हैं, जो मूल से एक दिन के लिए अलग है, तो आपको बस एक नया उदाहरण मिलेगा।
   • KeyValuePair<TKey, TValue> एक संरचना है जो एक जुड़े हुए कुंजी - मूल्य जोड़ी की अवधारणा को एनकोड करता है। यह संरचना केवल गणना के दौरान एक शब्दकोश की सामग्री का उत्पादन करने के लिए है। वास्तुकला के दृष्टिकोण से एक महत्वपूर्ण और मूल्य Dictionary<T> में अविभाज्य अवधारणाएं हैं। हालांकि, हमारे अंदर एक जटिल संरचना होती है, जहां एक कुंजी एक मूल्य से अलग होती है। एक उपयोगकर्ता के लिए एक कुंजी-मूल्य जोड़ी इंटरफ़ेस के संदर्भ में एक अविभाज्य अवधारणा है और एक डेटा संरचना का अर्थ है। यह अपने आप में एक संपूर्ण मूल्य है। यदि कोई कुंजी के लिए दूसरा मान प्रदान करता है, तो पूरी जोड़ी बदल जाएगी। इस प्रकार, वे एक इकाई का प्रतिनिधित्व करते हैं। यह इस मामले में एक संरचना को एक आदर्श संस्करण बनाता है।
   
   

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

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

1. न तो उदाहरण व्यवहार की विरासत को दर्शाता है। वे दिखाते हैं कि इन संस्थाओं के व्यवहार को विरासत में लेने की आवश्यकता नहीं है। वे स्वयंभू हैं। हालांकि, यदि हम कोड की प्रभावशीलता को ध्यान में रखते हैं, तो हम विकल्प को दूसरी तरफ से देखेंगे:
2. यदि हमें मानवरहित कोड से कुछ संरचित डेटा लेने की आवश्यकता है, तो हमें संरचनाएं चुननी चाहिए। हम डेटा संरचना को असुरक्षित पद्धति से भी पारित कर सकते हैं। एक संदर्भ प्रकार इसके लिए बिल्कुल उपयुक्त नहीं है।
3. एक संरचना आपकी पसंद है यदि कोई विधि विधि कॉल में डेटा (जैसा मान लौटा या एक विधि पैरामीटर के रूप में) पास करता है और विभिन्न स्थानों से समान मूल्य को संदर्भित करने की आवश्यकता नहीं है। सही उदाहरण ट्यूपल्स है। यदि कोई विधि tuples का उपयोग करके कई मान लौटाता है, तो यह एक ValueTuple लौटाएगा, जिसे एक संरचना के रूप में घोषित किया जाएगा। विधि ढेर पर जगह आवंटित नहीं करेगा, लेकिन धागे के ढेर का उपयोग करेगा, जहां मेमोरी आवंटन में कुछ भी खर्च नहीं होता है।
4. यदि आप एक ऐसी प्रणाली डिज़ाइन करते हैं जो छोटे आकार और जीवनकाल वाले बड़े ट्रैफ़िक का निर्माण करती है, तो संदर्भ प्रकारों का उपयोग करके या तो ऑब्जेक्ट्स के पूल में ले जाया जाएगा या यदि ऑब्जेक्ट्स के पूल के बिना, ढेर पर अनियंत्रित कचरा संचय के लिए। जीसी पर लोड बढ़ने से कुछ ऑब्जेक्ट पुरानी पीढ़ियों में बदल जाएंगे। ऐसे स्थानों में मूल्य प्रकारों का उपयोग करना (यदि यह संभव है) प्रदर्शन में वृद्धि देगा क्योंकि कुछ भी एसओएच को पारित नहीं करेगा। यह जीसी पर लोड को कम करेगा और एल्गोरिथ्म तेजी से काम करेगा;

मैंने जो कहा है, उस पर ध्यान देते हुए, यहाँ संरचनाओं का उपयोग करने के बारे में कुछ सलाह दी गई है:

1. संग्रह चुनते समय आपको बड़ी संरचनाओं को संग्रहीत करने वाले बड़े सरणियों से बचना चाहिए। इसमें सरणियों के आधार पर डेटा संरचनाएं शामिल हैं। यह बड़े ऑब्जेक्ट्स हीप और इसके विखंडन के लिए संक्रमण का कारण बन सकता है। यह सोचना गलत है कि अगर हमारी संरचना में बाइट प्रकार के 4 क्षेत्र हैं, तो 4 बाइट्स लगेंगे। हमें समझना चाहिए कि 32-बिट सिस्टम में प्रत्येक संरचना क्षेत्र 4 बाइट्स सीमाओं पर संरेखित होता है (प्रत्येक पता फ़ील्ड को 4 से बिल्कुल विभाजित किया जाना चाहिए) और 64-बिट सिस्टम में - 8 बाइट्स सीमाओं पर। एक सरणी का आकार एक संरचना और एक मंच के आकार पर निर्भर करता है, एक कार्यक्रम चलाना। 4 बाइट्स के साथ हमारे उदाहरण में - 85K / (4 से 8 बाइट्स प्रति फ़ील्ड * फ़ील्ड्स की संख्या = 4) माइनर हेडर का आकार प्लेटफॉर्म के आधार पर प्रति एरे लगभग 2 600 एलिमेंट्स के बराबर होता है (इसे नीचे राउंड किया जाना चाहिए) )। वह बहुत ज्यादा नहीं है। ऐसा प्रतीत हो सकता है कि हम आसानी से 20,000 तत्वों के एक जादू तक पहुंच सकते हैं
2. कभी-कभी आप डेटा के स्रोत के रूप में एक बड़े आकार की संरचना का उपयोग करते हैं और इसे एक वर्ग में एक क्षेत्र के रूप में रखते हैं, जबकि एक प्रति होने पर एक हज़ार उदाहरणों का उत्पादन होता है। तब आप संरचना के आकार के लिए एक वर्ग के प्रत्येक उदाहरण का विस्तार करते हैं। यह पीढ़ी शून्य की सूजन और पीढ़ी एक और यहां तक ​​कि दो को बदल देगा। यदि किसी वर्ग के उदाहरणों की अवधि कम होती है और आपको लगता है कि जीसी उन्हें पीढ़ी शून्य पर इकट्ठा करेगा - 1 एमएस के लिए, तो आप निराश होंगे। वे पहले से ही एक और दो पीढ़ी में हैं। इससे फर्क पड़ता है। यदि जीसी 1 एमएस के लिए पीढ़ी शून्य एकत्र करता है, तो एक और दो पीढ़ियों को बहुत धीरे से एकत्र किया जाता है जिससे दक्षता में कमी आएगी;
3. उसी कारण से आपको विधि कॉल की एक श्रृंखला के माध्यम से बड़ी संरचनाओं को पारित करने से बचना चाहिए। यदि सभी तत्व एक-दूसरे को कॉल करते हैं, तो ये कॉल स्टैक पर अधिक स्थान ले लेंगे और आपके आवेदन को StackOverflowException द्वारा मौत के लिए लाएंगे। अगला कारण प्रदर्शन है। जितनी अधिक प्रतियां होती हैं उतनी ही धीरे-धीरे सब कुछ काम करता है।

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

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

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