🚵 🧚🏾 🕧 जहां GetHashCode के .NET हाथ बढ़ रहे हैं 🚵 🧑🏽‍🤝‍🧑🏼 👨🏻‍🎨

परिचय

यह आलेख .NET प्लेटफ़ॉर्म पर हैश कोड की पीढ़ी पर केंद्रित है। विषय काफी दिलचस्प है, और मुझे लगता है कि किसी भी स्वाभिमानी .NET डेवलपर को यह जानना चाहिए। तो चलिए!

उनके क्षेत्रों के अलावा वस्तुओं में क्या संग्रहीत किया जाता है?

हम अपने लेख को उनके क्षेत्रों के अलावा एक संदर्भ प्रकार की वस्तुओं पर संग्रहीत करके सीखते हैं।

एक संदर्भ प्रकार के प्रत्येक ऑब्जेक्ट में एक तथाकथित हेडर (हेडर) होता है, जिसमें दो फ़ील्ड होते हैं: एक संकेतक जिसके प्रकार यह ऑब्जेक्ट है (मेथोडेबल पॉइंटर), साथ ही एक सिंक्रोनाइज़ेशन इंडेक्स (SyncBlockIndex)।

वे किस लिए हैं?

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

दूसरा क्षेत्र एक बहु-थ्रेडेड वातावरण के लिए आवश्यक है, अर्थात्, ताकि प्रत्येक वस्तु को थ्रेड-सुरक्षित उपयोग किया जा सके।

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

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

स्थिति की बेहतर समझ के लिए, निम्न चित्र पर विचार करें:

चित्र दिखाता है कि ObjectA और ObjectB एक ही प्रकार के हैं, क्योंकि उनका MethodTablePointer एक ही प्रकार को इंगित करता है। ObjectC एक अलग प्रकार का है। यह भी देखा गया है कि ObjectA और ObjectC सिंक्रोनाइज़ेशन ब्लॉक के एक पूल का उपयोग करते हैं, अर्थात, वे वास्तव में एक बहु-थ्रेडेड वातावरण का उपयोग करते हैं। ObjectB अपने SyncBlockIndex = -1 के बाद से पूल का उपयोग नहीं करता है।

अब हमने जांच करने के बाद कि वस्तुओं को कैसे संग्रहीत किया जाता है, हम हैश कोड की पीढ़ी के लिए आगे बढ़ सकते हैं।

GetHashCode संदर्भ प्रकारों के साथ कैसे काम करता है

तथ्य यह है कि GetHashCode विधि एक प्रबंधित हीप में किसी ऑब्जेक्ट का पता लौटाती है एक मिथक है। ऐसा नहीं हो सकता, इसकी असंगतता को देखते हुए, कचरा संग्रहकर्ता, ढेर को संकुचित करना, वस्तुओं को स्थानांतरित करता है और तदनुसार सभी के पते बदलता है।

यह व्यर्थ नहीं था कि मैंने आर्टिकल को सिंकबलॉक के स्पष्टीकरण के साथ शुरू किया, क्योंकि फ्रेमवर्क के पहले संस्करणों में, कुछ सिंकब्लॉक के फ्री इंडेक्स को संदर्भ प्रकार के हैश कोड के रूप में इस्तेमाल किया गया था। इस प्रकार, .NET 1.0 और .NET 1.1 में, GetHashCode पद्धति को कॉल करने से सिंकबलॉक और ऑब्जेक्ट इंडेक्स में सिंकबलॉकआईंडेक्स फ़ील्ड में निर्माण होता है। जैसा कि आप समझते हैं, यह एक हैश फ़ंक्शन के लिए एक अच्छा कार्यान्वयन नहीं है, क्योंकि सबसे पहले, अनावश्यक आंतरिक संरचनाएं बनाई जाती हैं जो स्मृति + समय को अपने निर्माण के लिए बर्बाद कर देती हैं, दूसरे, हैश कोड एक पंक्ति में जाएंगे, अर्थात, वे अनुमानित होंगे। यहां एक ब्लॉग का लिंक दिया गया है जिसमें सीएलआर डेवलपर्स में से एक का कहना है कि ऐसा कार्यान्वयन खराब है और वे इसे अगले संस्करण में बदल देंगे।

.NET 2.0 से शुरू होकर, हैश एल्गोरिथ्म बदल गया है। अब यह थ्रेड के प्रबंधन पहचानकर्ता का उपयोग करता है जिसमें विधि चलती है। यदि आप SSCLI20 में कार्यान्वयन पर विश्वास करते हैं, तो विधि इस प्रकार दिखती है:

inline DWORD GetNewHashCode() { // Every thread has its own generator for hash codes so that we won't get into a situation // where two threads consistently give out the same hash codes. // Choice of multiplier guarantees period of 2**32 - see Knuth Vol 2 p16 (3.2.1.2 Theorem A) DWORD multiplier = m_ThreadId*4 + 5; m_dwHashCodeSeed = m_dwHashCodeSeed*multiplier + 1; return m_dwHashCodeSeed; }

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

पहले की तरह, हैश कोड की गणना एक बार और ऑब्जेक्ट हेडर में सिंकब्लॉकइंडेक्स फ़ील्ड (यह एक सीएलआर ऑप्टिमाइज़ेशन है) में की जाती है। अब सवाल यह है कि अगर GetHashCode पद्धति को कॉल करने के बाद हमें सिंक्रोनाइज़ेशन इंडेक्स का उपयोग करने की आवश्यकता है तो क्या होगा? इसे कहां रिकॉर्ड करना है? और हैश कोड के साथ क्या करना है?

इन सवालों के जवाब के लिए, सिंकब्लॉक की संरचना पर विचार करें।

जब GetHashCode विधि को पहली बार कहा जाता है, CLR हैश कोड की गणना करता है और इसे SyncBlockIndex फ़ील्ड में दर्ज करता है। यदि SyncBlock ऑब्जेक्ट के साथ जुड़ा हुआ है, यानी SyncBlockIndex फ़ील्ड का उपयोग किया जाता है, तो CLR हैश कोड को सिंकब्लॉक में स्वयं लिखता है, यह आंकड़ा सिंकहॉक में स्थान को हैश कोड के भंडारण के लिए जिम्मेदार दिखाता है। जैसे ही सिंकब्लॉक को मुक्त किया जाता है, सीएलआर अपने शरीर से हैश कोड को सिंकब्लॉकइंडेक्स ऑब्जेक्ट के हेडर में कॉपी कर देता है। वह सब है।

GetHashCode महत्वपूर्ण प्रकारों के लिए कैसे काम करता है

अब बात करते हैं कि GetHashCode पद्धति महत्वपूर्ण प्रकारों के लिए कैसे काम करती है। मैं पहले से कहूंगा कि यह काफी दिलचस्प तरीके से काम करता है।

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

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

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

वैसे, इस संस्करण के कार्यान्वयन में एक बग था जो केवल .NET 4 में तय किया गया था। इसमें यह तथ्य शामिल था कि दशमलव प्रकार के लिए हैश कोड की सही गणना नहीं की गई थी।

कोड पर विचार करें

 decimal d1 = 10.0m; decimal d2 = 10.00000000000000000m;

संख्या के संदर्भ में, डी 1 और डी 2 बराबर हैं, लेकिन उनकी बिट प्रतिनिधित्व अलग हैं (दशमलव प्रतिनिधित्व की प्रकृति के कारण)। और चूंकि CLR xor हर 4 बाइट्स का होता है (जिनमें से केवल 4 बाइट्स होते हैं क्योंकि दशमलव में 16 बाइट्स होते हैं), अलग-अलग हैश कोड प्राप्त होते हैं। वैसे, यह बग न केवल दशमलव में, बल्कि किसी भी संरचना में भी प्रकट होता है जिसमें इस प्रकार होता है, और हैश कोड की गणना करने के लिए तेज़ संस्करण का भी उपयोग करता है।

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

CLR डेवलपर्स वैल्यू टाइप के गेटहैशकोड विधि पर टिप्पणी करते हैं:

 /*=================================GetHashCode================================== ** Action: Our algorithm for returning the hashcode is a little bit complex. We look ** for the first non-static field and get it's hashcode. If the type has no ** non-static fields, we return the hashcode of the type. We can't take the ** hashcode of a static member because if that member is of the same type as ** the original type, we'll end up in an infinite loop. **Returns: The hashcode for the type. **Arguments: None. **Exceptions: None. ==============================================================================*/ [MethodImplAttribute(MethodImplOptions.InternalCall)] public extern override int GetHashCode(); // Note that for correctness, we can't use any field of the value type // since that field may be mutable in some way. If we use that field // and the value changes, we may not be able to look up that type in a // hash table. For correctness, we need to use something unique to // the type of this object. // HOWEVER, we decided that the perf of returning a constant value (such as // the hash code for the type) would be too big of a perf hit. We're willing // to deal with less than perfect results, and people should still be // encouraged to override GetHashCode.

टिप्पणी

संरचना में अपने प्रकार के उदाहरण फ़ील्ड नहीं हो सकते। अर्थात्, निम्न कोड संकलित नहीं होगा:

 public struct Node { int data; Node node; }

यह इस तथ्य के कारण है कि संरचना शून्य मान नहीं ले सकती है। निम्न कोड पुष्टि करता है कि यह संभव नहीं है:

 var myNode = new Node(); myNode.node.node.node.node.node.node.node.node.node.......

हालांकि, अपने स्वयं के प्रकार के स्थिर क्षेत्र काफी स्वीकार्य हैं, क्योंकि वे इस संरचना के प्रकार के एकल उदाहरण में संग्रहीत हैं। अर्थात्, निम्न कोड पूरी तरह से मान्य है।

 public struct Node { int data; static Node node; }

टिप्पणी

स्थिति को बेहतर ढंग से समझने के लिए, निम्नलिखित कोड पर विचार करें:

 var k1 = new KeyValuePair<int, int>(10, 29); var k2 = new KeyValuePair<int, int>(10, 31); Console.WriteLine("k1 - {0}, k2 - {1}", k1.GetHashCode(), k2.GetHashCode()); var v1 = new KeyValuePair<int, string>(10, "abc"); var v2 = new KeyValuePair<int, string>(10, "def"); Console.WriteLine("v1 - {0}, v2 - {1}", v1.GetHashCode(), v2.GetHashCode());

पहले मामले में, संरचना में कोई संदर्भ फ़ील्ड नहीं है और फ़ील्ड के बीच कोई खाली दूरी नहीं है, चूंकि इंट फ़ील्ड 4 बाइट्स लेता है, इसलिए फास्ट संस्करण का उपयोग हैश कोड की गणना करने के लिए किया जाता है, इस प्रकार यह कंसोल पर प्रदर्शित होगा:

k1 - 411217769, k2 - 411217771

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

v1 - 411217780, वी 2 - 411217780

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

यदि आप GetHashCode विधि को ओवरराइड नहीं करते हैं, तो आप हैश तालिका में कुंजी के रूप में एक महत्वपूर्ण प्रकार का उपयोग करके प्रदर्शन पर एक बड़ी हिट प्राप्त कर सकते हैं।

GetHashCode स्ट्रिंग प्रकार के साथ कैसे काम करता है?

स्ट्रिंग क्लास GetHashCode पद्धति को ओवरराइड करती है। .NET 4.5 में इसका कार्यान्वयन इस प्रकार है:

GetHashCode X64

 public override unsafe int GetHashCode() { if (HashHelpers.s_UseRandomizedStringHashing) return string.InternalMarvin32HashString(this, this.Length, 0L); fixed (char* chPtr1 = this) { int num1 = 5381; int num2 = num1; char* chPtr2 = chPtr1; int num3; while ((num3 = (int) *chPtr2) != 0) { num1 = (num1 << 5) + num1 ^ num3; int num4 = (int) chPtr2[1]; if (num4 != 0) { num2 = (num2 << 5) + num2 ^ num4; chPtr2 += 2; } else break; } return num1 + num2 * 1566083941; } }

यह 64-बिट मशीन के लिए कोड है, लेकिन अगर हम निर्देशों के साथ सामान्य कोड को देखते हैं

GetHashCode

 public int GetHashCode() { #if FEATURE_RANDOMIZED_STRING_HASHING if(HashHelpers.s_UseRandomizedStringHashing) { return InternalMarvin32HashString(this, this.Length, 0); } #endif // FEATURE_RANDOMIZED_STRING_HASHING unsafe { fixed (char* src = this) { #if WIN32 int hash1 = (5381<<16) + 5381; #else int hash1 = 5381; #endif int hash2 = hash1; #if WIN32 // 32 bit machines. int* pint = (int *)src; int len = this.Length; while (len > 2) { hash1 = ((hash1 << 5) + hash1 + (hash1 >> 27)) ^ pint[0]; hash2 = ((hash2 << 5) + hash2 + (hash2 >> 27)) ^ pint[1]; pint += 2; len -= 4; } if (len > 0) { hash1 = ((hash1 << 5) + hash1 + (hash1 >> 27)) ^ pint[0]; } #else int c; char* s = src; while ((c = s[0]) != 0) { hash1 = ((hash1 << 5) + hash1) ^ c; c = s[1]; if (c == 0) break; hash2 = ((hash2 << 5) + hash2) ^ c; s += 2; } #endif return hash1 + (hash2 * 1566083941); } } }

फिर ध्यान दें कि 32 या 64 बिट मशीन के आधार पर मतभेद हैं।

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

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

यदि आप ध्यान दें, GetHashCode पद्धति के कार्यान्वयन में वह कोड दिखाई दिया जो पहले मौजूद नहीं था:

 if (HashHelpers.s_UseRandomizedStringHashing) return string.InternalMarvin32HashString(this, this.Length, 0L);

यह पता चलता है कि .NET 4.5 में प्रत्येक डोमेन के लिए स्ट्रिंग्स के लिए हैश कोड की गणना करने की क्षमता है। इस प्रकार, विशेषता मान को 1 पर सेट करके, उस डोमेन के आधार पर हैश कोड की गणना संभव है जिसमें विधि कहा जाता है। इस प्रकार, अलग-अलग डोमेन में एक ही स्ट्रिंग के अलग-अलग हैश कोड होंगे। इस हैश कोड को उत्पन्न करने वाली विधि गुप्त है और इसके कार्यान्वयन का खुलासा नहीं किया गया है।

कैसे प्रतिनिधि काम करता है

प्रतिनिधियों के लिए GetHashCode पद्धति के कार्यान्वयन पर चर्चा करने से पहले, हम बात करेंगे कि इन्हें कैसे लागू किया जाता है।

प्रत्येक प्रतिनिधि मल्टीकास्टडेगेट वर्ग से विरासत में मिला है, जो बदले में प्रतिनिधि वर्ग से विरासत में मिला है। यह पदानुक्रम ऐतिहासिक रूप से विकसित हुआ है, क्योंकि एक वर्ग मल्टीकास्टडेलेगेट के साथ कर सकता है।

डेलीगेट वर्ग में GetHashCode पद्धति का कार्यान्वयन इस तरह दिखता है

 public override int GetHashCode() { return this.GetType().GetHashCode(); }

यह है, एक प्रतिनिधि प्रकार हैश वास्तव में वापस आ गया है। यह पता चला है कि कॉलिंग के लिए अलग-अलग तरीकों वाले एक ही प्रकार के प्रतिनिधि हमेशा एक ही हैश कोड लौटाते हैं।

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

मल्टीकास्टडेलेगेट वर्ग में विधि का कार्यान्वयन इस तरह दिखता है

 public override sealed int GetHashCode() { if (this.IsUnmanagedFunctionPtr()) return ValueType.GetHashCodeOfPtr(this._methodPtr) ^ ValueType.GetHashCodeOfPtr(this._methodPtrAux); object[] objArray = this._invocationList as object[]; if (objArray == null) return base.GetHashCode(); int num = 0; for (int index = 0; index < (int) this._invocationCount; ++index) num = num * 33 + objArray[index].GetHashCode(); return num; }

जैसा कि आप जानते हैं, एक प्रतिनिधि अपने तरीकों को _invocationList सूची में संग्रहीत करता है, यदि एक से अधिक हो।

यदि प्रतिनिधि में केवल एक विधि है, तो ऊपर दिए गए कोड में objArray = null और, तदनुसार, प्रतिनिधि का हैश कोड प्रतिनिधि प्रकार के हैश कोड के बराबर होगा।

 object[] objArray = this._invocationList as object[]; if (objArray == null) return base.GetHashCode();

स्थिति को स्पष्ट करने के लिए, निम्नलिखित कोड पर विचार करें

 Func<int> f1 = () => 1; Func<int> f2 = () => 2;

इन प्रतिनिधियों के हैश कोड किसी प्रकार के फनक <int> के हैश कोड के बराबर हैं, अर्थात वे एक दूसरे के बराबर हैं।

 Func<int> f1 = () => 1; Func<int> f2 = () => 2; f1 += () => 3; f2 += () => 4;

इस मामले में, प्रतिनिधियों के हैश कोड भी मेल खाते हैं, हालांकि तरीके अलग हैं। इस स्थिति में, हैश कोड की गणना करने के लिए निम्न कोड का उपयोग किया जाता है।

 int num = 0; for (int index = 0; index < (int) this._invocationCount; ++index) num = num * 33 + objArray[index].GetHashCode(); return num;

और आखिरी मामला

 Func<int> f1 = () => 1; Func<int> f2 = () => 2; f1 += () => 3; f1 += () => 5; f2 += () => 4;

हैश कोड इस तथ्य के कारण अलग होंगे कि इन प्रतिनिधियों के लिए विधियों की संख्या बराबर नहीं है (प्रत्येक विधि परिणामी हैश कोड को प्रभावित करती है)।

अनाम प्रकारों के लिए GetHashCode कैसे काम करता है

जैसा कि आप जानते हैं, अनाम प्रकार C # 3.0 में एक नई विशेषता है। इसके अलावा, यह भाषा की एक विशेषता है, तथाकथित कृत्रिम शर्करा, क्योंकि सीएलआर उनके बारे में कुछ भी नहीं जानता है।

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

 var newType = new { Name = "Timur", Age = 20, IsMale = true };

ऐसे अनाम प्रकार के लिए, निम्न कोड जनरेट किया जाएगा:

 public override int GetHashCode() { return -1521134295 * (-1521134295 * (-1521134295 * -974875401 + EqualityComparer<string>.Default.GetHashCode(this.Name)) + EqualityComparer<int >.Default.GetHashCode(this.Age)) + EqualityComparer<bool>.Default.GetHashCode(this.IsMale); }

टिप्पणी

यह देखते हुए कि GetHashCode विधि को समान विधि द्वारा ओवरराइड किया गया है, इसे भी उसी के अनुसार ओवरराइड किया जाना चाहिए।

 var newType = new { Name = "Timur", Age = 20, IsMale = true }; var newType1 = new { Name = "Timur", Age = 20, IsMale = true }; if (newType.Equals(newType1)) Console.WriteLine("method Equals return true"); else Console.WriteLine("method Equals return false"); if (newType == newType1) Console.WriteLine("operator == return true"); else Console.WriteLine("operator == return false");

निम्नलिखित कंसोल पर प्रदर्शित किया जाएगा:

विधि बराबर होती है
ऑपरेटर == झूठे लौटें

बात यह है कि अनाम प्रकार समतुल्य विधि को इस तरह से परिभाषित करता है कि यह सभी क्षेत्रों की जाँच करता है क्योंकि यह ValueType (केवल प्रतिबिंब के बिना) के साथ किया जाता है, लेकिन समानता ऑपरेटर को फिर से परिभाषित नहीं करता है। इस प्रकार, समतुल्य विधि मूल्य की तुलना करती है, जबकि समानता ऑपरेटर संदर्भ द्वारा तुलना करता है।

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

टिप्पणी

निष्कर्ष

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

पढ़ने के लिए धन्यवाद! मुझे उम्मीद है कि यह लेख मददगार रहा है।

लेख के लिए कृपया अद्यतन चित्र प्रदान करने के लिए ड्रीमवल्कर के उपयोगकर्ता को धन्यवाद।

जहां GetHashCode के .NET हाथ बढ़ रहे हैं

परिचय

उनके क्षेत्रों के अलावा वस्तुओं में क्या संग्रहीत किया जाता है?

GetHashCode संदर्भ प्रकारों के साथ कैसे काम करता है

GetHashCode महत्वपूर्ण प्रकारों के लिए कैसे काम करता है

टिप्पणी

टिप्पणी

GetHashCode स्ट्रिंग प्रकार के साथ कैसे काम करता है?

कैसे प्रतिनिधि काम करता है

अनाम प्रकारों के लिए GetHashCode कैसे काम करता है

टिप्पणी

टिप्पणी

निष्कर्ष

More articles: