Runtime: हैश कोड के संयोजन में सहायता के लिए हैशकोड प्रकार जोड़ना

यदि आप कुछ जल्दी और गंदा चाहते हैं तो आप ValueTuple.Create(field1, field2).GetHashCode() उपयोग कर सकते हैं। यह वही एल्गोरिदम है जो Tuple में उपयोग किया जाता है (जो उस मामले के लिए, Objects ) और इसमें आवंटन ओवरहेड नहीं है।

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

@JonHanna मुझे लगता है कि वे प्रश्न भी लागू होते हैं, उदाहरण के लिए, string.GetHashCode() । मुझे नहीं लगता कि Hash करना उससे कहीं अधिक कठिन क्यों होना चाहिए।

वास्तव में, यह आसान होना चाहिए, क्योंकि विशेष आवश्यकताओं वाले उपयोगकर्ता आसानी से Hash का उपयोग करना बंद कर सकते हैं, लेकिन string.GetHashCode() का उपयोग करना बंद करना कठिन है।

+1

हमारे पास ASP.NET में इनमें से एक है, https://github.com/aspnet/Common/blob/dev/src/Microsoft.Extensions.HashCodeCombiner.Sources/HashCodeCombiner.cs। यह इनलाइन फ्रेंडली भी है।

यदि आप कुछ जल्दी और गंदा चाहते हैं तो आप ValueTuple.Create(field1, field2).GetHashCode() का उपयोग कर सकते हैं।

आह, अच्छा विचार, मैंने इस पोस्ट को बनाते समय ValueTuple बारे में नहीं सोचा था। दुर्भाग्य से मुझे नहीं लगता कि यह सी # 7/अगले ढांचे के रिलीज होने तक उपलब्ध होगा, या यहां तक ​​​​कि यह भी पता चलेगा कि यह प्रदर्शन करने वाला होगा (उन संपत्ति/विधि कॉल EqualityComparer जोड़ सकते हैं)। लेकिन मैंने इसे मापने के लिए कोई बेंचमार्क नहीं लिया है, इसलिए मुझे वास्तव में पता नहीं चलेगा। मुझे लगता है कि हैशिंग के लिए एक समर्पित/सरल वर्ग होना चाहिए कि लोग हैकिश वर्कअराउंड के रूप में टुपल्स का उपयोग किए बिना उपयोग कर सकें।

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

बिल्कुल सहमत, लेकिन मुझे नहीं लगता कि अधिकांश कार्यान्वयन इसे ध्यान में रखते हैं, उदाहरण के लिए ArraySegment का वर्तमान कार्यान्वयन बहुत सरल है। इस वर्ग का मुख्य उद्देश्य (आवंटन से बचने के साथ) उन लोगों के लिए एक कार्यान्वयन प्रदान करना होगा जो हैशिंग के बारे में ज्यादा नहीं जानते हैं, ताकि उन्हें इस तरह से कुछ बेवकूफी करने से रोका जा सके। जिन लोगों को आपके द्वारा वर्णित स्थितियों से निपटने की आवश्यकता है, वे अपने स्वयं के हैशिंग एल्गोरिदम को लागू कर सकते हैं।

दुर्भाग्य से मुझे नहीं लगता कि यह सी # 7/अगले ढांचे के रिलीज होने तक उपलब्ध होगा

मुझे लगता है कि आप इसे सी # 2 के साथ उपयोग कर सकते हैं, न कि अंतर्निर्मित समर्थन के साथ।

या यहां तक ​​​​कि यह भी पता है कि यह प्रदर्शन करने वाला होगा (उन संपत्ति/विधि कॉल को समानता कॉम्पैयर में जोड़ सकते हैं)

यह वर्ग अलग तरीके से क्या करेगा? यदि स्पष्ट रूप से obj == null ? 0 : obj.GetHashCode() को कॉल करना कोई तेज़ है, तो उसे ValueTuple में ले जाया जाना चाहिए।

मैं +1 करने के लिए इस प्रस्ताव को कुछ हफ़्ते पहले इच्छुक होता है, लेकिन मैं कम के आलोक में इच्छुक हूँ ValueTuple का उपयोग करने का चाल के आवंटन भूमि के ऊपर कम करने Tuple इस के लिए, ऐसा लगता है कि यह मेरे लिए दो मलों के बीच है: यदि आपको विशेष रूप से विशिष्ट कुछ की आवश्यकता नहीं है तो आप ValueTuple उपयोग कर सकते हैं, लेकिन यदि आपको उससे आगे कुछ चाहिए, तो इस तरह की कक्षा दूर नहीं जा रही है पर्याप्त।

और जब हमारे पास C#7 होता है, तो इसे और भी आसान बनाने के लिए इसमें सिंटैक्टिक शुगर होगी।

@JonHanna

यह वर्ग अलग तरीके से क्या करेगा? अगर स्पष्ट रूप से obj == null को कॉल करना है? 0 : obj.GetHashCode() किसी भी तेज है, इससे ValueTuple में ले जाया जाना चाहिए।

क्यों न ValueTuple हैश कोड प्राप्त करने के लिए केवल Hash वर्ग का उपयोग करें? यह फ़ाइल में एलओसी को भी काफी कम कर देगा (जो अभी लगभग ~ 2000 लाइनें है)।

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

यदि आपको विशेष रूप से कुछ विशेष की आवश्यकता नहीं है तो आप ValueTuple . का उपयोग कर सकते हैं

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

कि मैं वास्तव में पीछे रह सकता हूं।

शायद इस मुद्दे के दायरे से बाहर। लेकिन एक हैशिंग नेमस्पेस जहां हम विशेषज्ञों द्वारा लिखे गए उच्च-प्रदर्शन क्रिप्टोग्राफ़िक और गैर-क्रिप्टोग्राफ़िक हैश पा सकते हैं, यहाँ एक जीत होगी।

उदाहरण के लिए, हमें xxHash32, xxHash64, Metro128 को कोड करना था और 128 से 64 तक और 64 से 32 बिट्स तक खुद को डाउनसैंपलिंग करना था। अनुकूलित कार्यों की एक सरणी होने से डेवलपर्स को अपने स्वयं के गैर-अनुकूलित और/या छोटी गाड़ी लिखने से बचने में मदद मिल सकती है (मुझे पता है, हमने अपने आप में भी कुछ बग पाए हैं); लेकिन फिर भी जरूरतों के आधार पर चुनने में सक्षम है।

रुचि होने पर हम खुशी-खुशी अपने कार्यान्वयन दान करेंगे, ताकि विशेषज्ञों द्वारा उनकी समीक्षा की जा सके और उन्हें और अनुकूलित किया जा सके।

@redknightlois मुझे इस तरह के प्रयास में अपने स्पूकीहैश कार्यान्वयन को जोड़ने में खुशी होगी।

@svick स्ट्रिंग के साथ सावधान।

@terrajobst , एपीआई ट्राइएज/समीक्षा कतार में यह कितनी दूर है? मुझे लगता है कि यह एक साधारण एपीआई है जिसे हम हमेशा मंच में जोड़ना चाहते थे और संभवतः अब हमारे पास वास्तव में ऐसा करने के लिए पर्याप्त महत्वपूर्ण द्रव्यमान है?

सीसी: @ ellismg

मुझे लगता है कि यह अपनी वर्तमान स्थिति में समीक्षा के लिए तैयार है।

@ मेलिनो यह बहुत अच्छा है! मैंने इसे और अधिक संक्षिप्त बनाने के लिए प्रस्ताव को थोड़ा सा साफ कर दिया है, और अंत में कुछ प्रश्न भी जोड़े हैं जो मुझे लगता है कि संबोधित किया जाना चाहिए।

@jamesqo long आधारित भी होना चाहिए।

@redknightlois , उचित लगता है। मैंने long के Combine ओवरलोड को शामिल करने के प्रस्ताव को अपडेट किया।

क्या @JonHanna का सुझाव काफी अच्छा नहीं है?

C# return ValueTuple.Create(a, b, c).GetHashCode();

जब तक पर्याप्त पर्याप्त कारण न हों, यह पर्याप्त क्यों नहीं है, हमें नहीं लगता कि यह कटौती कर रहा है।

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

एक उदाहरण से समझाता हूँ।

मान लीजिए कि हम वास्तविक कोड लेते हैं जिसका उपयोग ValueTuple लिए किया जा रहा है और इसे कॉल करने के लिए स्थिरांक का उपयोग करें।

        internal static class HashHelpers
        {
            public static int Combine(int h1, int h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                uint shift5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryStaticCall()
        {
            return HashHelpers.Combine(10202, 2003);
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryValueTuple()
        {
            return ValueTuple.Create(10202, 2003).GetHashCode();
        }
    }

अब एक अनुकूलन संकलक संभावना के तहत कोई अंतर नहीं होना चाहिए, लेकिन वास्तव में वहाँ है।

यह ValueTuple के लिए वास्तविक कोड है

तो अब यहाँ क्या देखा जा सकता है? पहले हम स्टैक में एक स्ट्रक्चर बना रहे हैं, फिर हम वास्तविक हैश कोड कह रहे हैं।

अब इसकी तुलना HashHelper.Combine के उपयोग से करें जो सभी उद्देश्यों के लिए Hash.Combine का वास्तविक कार्यान्वयन हो सकता है

मैं जानती हूँ!!!
लेकिन वहाँ रुकने नहीं देता... वास्तविक मापदंडों का उपयोग करते हैं:

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryStaticCall(int h1, int h2)
        {
            return HashHelpers.Combine(h1, h2);
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryValueTuple(int h1, int h2)
        {
            return ValueTuple.Create(h1, h2).GetHashCode();
        }

        static unsafe void Main(string[] args)
        {
            var g = new Random();
            int h1 = g.Next();
            int h2 = g.Next(); 
            Console.WriteLine(TryStaticCall(h1, h2));
            Console.WriteLine(TryValueTuple(h1, h2));
        }

अच्छी बात यह है कि यह बेहद स्थिर है। लेकिन आइए इसकी तुलना विकल्प से करें:

अब ओवरबोर्ड चलते हैं...

        internal static class HashHelpers
        {
            public static int Combine(int h1, int h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                uint shift5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }
            public static int Combine(int h1, int h2, int h3, int h4)
            {
                return Combine(Combine(h1, h2), Combine(h3, h4));
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryStaticCall(int h1, int h2, int h3, int h4)
        {
            return HashHelpers.Combine(h1, h2, h3, h4);
        }

और परिणाम बहुत ही निदर्शी है

मैं वास्तव में उस वास्तविक कोड का निरीक्षण नहीं कर सकता जो जेआईटी कॉल के लिए उत्पन्न करता है, लेकिन प्रस्ताव को शामिल करने का औचित्य साबित करने के लिए केवल प्रस्तावना और एपिलॉग पर्याप्त है।

विश्लेषण का टेकअवे सरल है: होल्डिंग प्रकार struct है इसका मतलब यह नहीं है कि यह मुफ़्त है :)

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

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

@terrajobst , इस प्रस्ताव के लिए प्रदर्शन एक प्रमुख प्रेरणा थी लेकिन केवल एक ही नहीं। एक समर्पित प्रकार होने से खोजे जाने में मदद मिलेगी; सी # 7 में बिल्ट-इन टुपल सपोर्ट के साथ भी, डेवलपर्स को यह नहीं पता होना चाहिए कि वे मूल्य के बराबर हैं। अगर वे ऐसा करते भी हैं, तो वे भूल सकते हैं कि टुपल्स GetHashCode ओवरराइड करते हैं, और संभवत: Google के पास .NET में GetHashCode को कैसे लागू किया जाए।

साथ ही, ValueTuple.Create.GetHashCode का उपयोग करने के साथ एक सूक्ष्म शुद्धता समस्या है। पिछले 8 तत्व, केवल अंतिम 8 तत्व हैश किए गए हैं; बाकी को नजरअंदाज कर दिया जाता है।

@terrajobst RavenDB में GetHashCode के प्रदर्शन का हमारे बॉटमलाइन पर इतना प्रभाव पड़ा कि हमने अत्यधिक अनुकूलित रूटीन के एक पूरे सेट को लागू करना समाप्त कर दिया। यहां तक ​​​​कि रोसलिन की अपनी आंतरिक हैशिंग भी है https://github.com/dotnet/roslyn/blob/master/src/Compilers/Core/Portable/InternalUtilities/Hash.cs भी विशेष रूप से यहां रोसलिन पर चर्चा की जांच करें: https://github .com/dotnet/coreclr/issues/1619 ... इसलिए जब प्रदर्शन महत्वपूर्ण होता है तो हम प्रदान किए गए प्लेटफॉर्म का उपयोग नहीं कर सकते हैं और अपना खुद का रोल करना होगा (और परिणामों का भुगतान करना होगा)।

साथ ही @jamesqo मुद्दा पूरी तरह से मान्य है। इतने सारे हैश को संयोजित करने की आवश्यकता नहीं है, लेकिन 1M मामलों के लिए कोई है जो उस एक के साथ चट्टान पर कदम रखने वाला है।

@JonHanna

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

तो आप कह रहे हैं कि एक सहायक वर्ग जोड़ना बुरा होगा, क्योंकि यह लोगों को उचित हैश करने के तरीके के बारे में सोचने के बिना सहायक कार्य में फेंकने के लिए प्रोत्साहित करेगा?

ऐसा लगता है कि विपरीत सच होगा, वास्तव में; Hash.Combine को आम तौर पर GetHashCode कार्यान्वयन में सुधार करना चाहिए। जो लोग हैशिंग करना जानते हैं, वे यह देखने के लिए Hash.Combine का मूल्यांकन कर सकते हैं कि क्या यह उनके उपयोग के मामले में फिट बैठता है। न्यूबीज जो वास्तव में हैशिंग के बारे में नहीं जानते हैं, वे घटक क्षेत्रों को केवल xor-ing (या इससे भी बदतर, जोड़ने) के बजाय Hash.Combine उपयोग करेंगे क्योंकि वे नहीं जानते कि उचित हैश कैसे करें।

हमने इस पर थोड़ी और चर्चा की और आपने हमें आश्वस्त किया :-)

कुछ और प्रश्न:

1. हमें यह तय करने की जरूरत है कि इस प्रकार को कहां रखा जाए। एक नया नामस्थान पेश करना अजीब लगता है; हालांकि System.Numerics काम कर सकता है। System.Collections.Generic भी काम कर सकता है, क्योंकि इसमें तुलनाकर्ता हैं और हैशिंग का उपयोग अक्सर संग्रह के संदर्भ में किया जाता है।
2. क्या हमें अज्ञात संख्या में हैश कोड को संयोजित करने के लिए आवंटन-मुक्त बिल्डर पैटर्न प्रदान करना चाहिए?

पर (2) @Eilon यह कहना था:

संदर्भ के लिए, ASP.NET Core (और इसके पूर्ववर्ती और संबंधित प्रोजेक्ट) एक HashCodeCombiner का उपयोग करते हैं: https://github.com/aspnet/Common/blob/dev/src/Microsoft.Extensions.HashCodeCombiner.Sources/HashCodeCombiner.cs

( @ डेविड फाउलर ने कई महीने पहले गिटहब थ्रेड में इसका उल्लेख किया था।)

और यह एक उदाहरण उपयोग है: https://github.com/aspnet/Mvc/blob/760c8f38678118734399c58c2dac981ea6e47046/src/Microsoft.AspNetCore.Mvc.Razor/Internal/ViewLocationCacheKey.cs#L129 -L144

``` सी#
वर हैशकोड कॉम्बिनर = हैशकोड कॉम्बिनर। स्टार्ट ();
हैशकोड कॉम्बिनर। जोड़ें (IsMainPage? 1: 0);
हैशकोड कॉम्बिनर। जोड़ें (व्यूनाम, स्ट्रिंग कॉमपेयर। ऑर्डिनल);
हैशकोड कॉम्बिनर। जोड़ें (नियंत्रक नाम, स्ट्रिंग कॉम्पैरर। ऑर्डिनल);
हैशकोड कॉम्बिनर। जोड़ें (क्षेत्रनाम, स्ट्रिंग कॉम्पेयरर। ऑर्डिनल);

अगर (ViewLocationExpanderValues!= null)
{
foreach (ViewLocationExpanderValues ​​​​में var आइटम)
{
हैशकोड कॉम्बिनर। जोड़ें (आइटम। कुंजी, स्ट्रिंग कॉम्पेयरर। ऑर्डिनल);
हैशकोड कॉम्बिनर। जोड़ें (आइटम। वैल्यू, स्ट्रिंग कॉम्पैरर। ऑर्डिनल);
}
}

वापसी हैशकोड कॉम्बिनर;
```

हमने इस पर थोड़ी और चर्चा की और आपने हमें आश्वस्त किया :-)

मैं

एक नया नामस्थान पेश करना अजीब लगता है; System.Numerics हालांकि काम कर सकता है।

यदि हम एक नया नाम स्थान नहीं जोड़ने का निर्णय लेते हैं, तो यह ध्यान दिया जाना चाहिए कि कोई भी कोड जिसमें Hash नामक एक वर्ग है और एक using System.Numerics निर्देश अस्पष्ट प्रकार की त्रुटि के साथ संकलित करने में विफल रहेगा।

क्या हमें अज्ञात संख्या में हैश कोड को संयोजित करने के लिए आवंटन-मुक्त बिल्डर पैटर्न प्रदान करना चाहिए?

यह एक महान विचार की तरह लग रहा है। कुछ प्रारंभिक सुझावों के रूप में, शायद हमें इसे HashBuilder (एक ला StringBuilder ) नाम देना चाहिए और इसे आसान बनाने के लिए प्रत्येक Add विधि के बाद इसे return this रखना चाहिए हैश जोड़ने के लिए, जैसे:

public override int GetHashCode()
{
    return HashBuilder.Create(_field1)
        .Add(_field2)
        .Add(_field3)
        .ToHash();
}

@jamesqo कृपया थ्रेड पर सहमति होने पर प्रस्ताव को शीर्ष पर अपडेट करें। इसके बाद हम अंतिम समीक्षा कर सकते हैं। जैसे ही आप डिज़ाइन चलाते हैं, आपको अभी के लिए असाइन करना ;-)

यदि हम एक नया नाम स्थान नहीं जोड़ने का निर्णय लेते हैं, तो यह ध्यान दिया जाना चाहिए कि कोई भी कोड जिसमें Hash नामक एक वर्ग है और एक using System.Numerics निर्देश अस्पष्ट प्रकार की त्रुटि के साथ संकलित करने में विफल रहेगा।

वास्तविक परिदृश्य पर निर्भर करता है। कई मामलों में संकलक आपके प्रकार को पसंद करेगा क्योंकि निर्देशों का उपयोग करने पर विचार करने से पहले संकलन इकाई के परिभाषित नामस्थान पदानुक्रम को चलाया जाता है।

लेकिन फिर भी: एपीआई जोड़ना एक स्रोत तोड़ने वाला परिवर्तन हो सकता है। हालांकि, इससे बचना अव्यावहारिक है, यह मानते हुए कि हम आगे की प्रगति करना चाहते हैं हम आम तौर पर संघर्षों से बचने का प्रयास करते हैं, उदाहरण के लिए, ऐसे नामों का उपयोग करके जो बहुत सामान्य नहीं हैं। उदाहरण के लिए, मुझे नहीं लगता कि हमें Hash टाइप करना चाहिए। मुझे लगता है कि HashCode शायद बेहतर होगा।

कुछ प्रारंभिक सुझावों के रूप में, शायद हमें इसे हैशबिल्डर नाम देना चाहिए

पहले सन्निकटन के रूप में मैं स्टैटिक्स और बिल्डर को एक ही प्रकार में संयोजित करने के बारे में सोच रहा था, जैसे:

``` सी#
नेमस्पेस सिस्टम
{
सार्वजनिक संरचना हैशकोड
{
सार्वजनिक स्थैतिक इंट कॉम्बिनेशन (इंट हैश 1, इंट हैश 2);
सार्वजनिक स्थैतिक इंट कॉम्बिनेशन (इंट हैश 1, इंट हैश 2, इंट हैश 3);
सार्वजनिक स्थैतिक इंट कॉम्बिनेशन (इंट हैश 1, इंट हैश 2, इंट हैश 3, इंट हैश 4);
सार्वजनिक स्थैतिक इंट कॉम्बिनेशन (इंट हैश 1, इंट हैश 2, इंट हैश 3, इंट हैश 4, इंट हैश 5);
सार्वजनिक स्थैतिक इंट कॉम्बिनेशन (इंट हैश 1, इंट हैश 2, इंट हैश 3, इंट हैश 4, इंट हैश 5, इंट हैश 6);

    public static long Combine(long hash1, long hash2);
    public static long Combine(long hash1, long hash2, long hash3);
    public static long Combine(long hash1, long hash2, long hash3, long hash4);
    public static long Combine(long hash1, long hash2, long hash3, long hash4, long hash5);
    public static long Combine(long hash1, long hash2, long hash3, long hash4, long hash5, longhash6);

    public static int CombineHashCodes<T1, T2>(T1 o1, T2 o2);
    public static int CombineHashCodes<T1, T2, T3>(T1 o1, T2 o2, T3 o3);
    public static int CombineHashCodes<T1, T2, T3, T4>(T1 o1, T2 o2, T3 o3, T4 o4);
    public static int CombineHashCodes<T1, T2, T3, T4, T5>(T1 o1, T2 o2, T3 o3, T4 o4, T5 o5);
    public static int CombineHashCodes<T1, T2, T3, T4, T5, T6>(T1 o1, T2 o2, T3 o3, T4 o4, T5 o5, T6 o6);

    public void Combine(int hashCode);
    public void Combine(long hashCode);
    public void Combine<T>(T obj);
    public void Combine(string text, StringComparison comparison);

    public int Value { get; }
}

}

This allows for code like this:

``` C#
return HashCode.Combine(value1, value2);

साथ ही साथ:

``` सी#
वर हैशकोड = नया हैशकोड ();
हैशकोड। कॉम्बाइन (IsMainPage? 1: 0);
हैशकोड। कॉम्बाइन (व्यूनाम, स्ट्रिंग कॉम्पैरर। ऑर्डिनल);
हैशकोड। कॉम्बिन (नियंत्रक नाम, स्ट्रिंग कॉम्पेयर। ऑर्डिनल);
हैशकोड। कॉम्बिन (क्षेत्रनाम, स्ट्रिंग कॉम्पैयर। ऑर्डिनल);

अगर (ViewLocationExpanderValues!= null)
{
foreach (ViewLocationExpanderValues ​​​​में var आइटम)
{
हैशकोड। कॉम्बिनेशन (आइटम। की, स्ट्रिंगकॉमपेयर। ऑर्डिनल);
हैशकोड। कॉम्बाइन (आइटम। वैल्यू, स्ट्रिंगकॉमपेयर। ऑर्डिनल);
}
}

वापसी हैशकोड। मूल्य;
```

विचार?

मुझे जंजीर कॉल के बारे में @jamesqo का विचार पसंद है (उदाहरण के तरीकों से this लौटाएं Combine )।

मैं यहां तक ​​​​कि स्थिर तरीकों को पूरी तरह से हटाने और केवल उदाहरण विधियों को रखने के लिए भी जाऊंगा ...

Combine(long hashCode) बस int नीचे आ जाएगा। क्या हम वाकई ऐसा चाहते हैं?
पहली जगह में long ओवरलोड के लिए उपयोग केस क्या है?

@karelz कृपया उन्हें न हटाएं,

नाम संघर्ष से बचने के लिए हमने Hashing स्थिर वर्ग का उपयोग किया और कोड अच्छा दिखता है।

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

@redknightlois जिज्ञासु, यदि संरचना (इस मामले में HashCode ) एक रजिस्टर में फिट हो सकती है, तो क्या JIT कोई भी बदतर कोड उत्पन्न करता है? यह केवल int बड़ा होगा।

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

संपादित करें: मैं देख रहा हूं कि @karelz ने पहले ही मेरी बातों का उल्लेख यहां कर दिया है।

@karelz , मैं int -साइज्ड स्ट्रक्चर के लिए सभ्य कोड उत्पन्न करता है (जो मेरा मानना ​​​​है कि यह करता है, ImmutableArray उदाहरण के लिए कोई ओवरहेड नहीं है) तो स्थिर अधिभार हैं अनावश्यक और हटाया जा सकता है।

@terrajobst मेरे पास कुछ और विचार हैं:

• मुझे लगता है कि हम आपके और मेरे विचारों को थोड़ा जोड़ सकते हैं। HashCode एक अच्छा नाम लगता है; यह बिल्डर पैटर्न के बाद एक परिवर्तनशील संरचना होना जरूरी नहीं है। इसके बजाय, यह int आसपास एक अपरिवर्तनीय आवरण हो सकता है, और प्रत्येक Combine ऑपरेशन एक नया HashCode मान लौटा सकता है। उदाहरण के लिए

public struct HashCode
{
    private readonly int _hash;

    public HashCode Combine(int hash) => return new HashCode(CombineCore(_hash, hash));

    public HashCode Combine<T>(T item) => Combine(EqualityComparer<T>.Default.GetHashCode(item));
}

// Usage
HashCode combined = new HashCode(_field1)
    .Combine(_field2)
    .Combine(_field3);

• हमारे पास int रूपांतरण के लिए बस एक निहित ऑपरेटर होना चाहिए ताकि लोगों को उस अंतिम .Value कॉल की आवश्यकता न हो।
• रे Combine , क्या यह सबसे अच्छा नाम है? यह अधिक वर्णनात्मक लगता है, लेकिन Add छोटा और टाइप करने में आसान है। ( Mix एक और विकल्प है, लेकिन यह टाइप करने के लिए थोड़ा दर्दनाक है।)
  
  
  
  • public void Combine(string text, StringComparison comparison) : मुझे नहीं लगता कि यह वास्तव में एक ही प्रकार का है, क्योंकि यह स्ट्रिंग्स से असंबंधित है। इसके अलावा, उन दुर्लभ समयों के लिए StringComparer.XXX.GetHashCode(str) लिखना काफी आसान है जो आपको ऐसा करने की आवश्यकता है।
  
  
  • हमें इस प्रकार से लंबे ओवरलोड को हटाना चाहिए और लंबे समय के लिए एक अलग HashCode प्रकार रखना चाहिए। Int64HashCode , या LongHashCode जैसा कुछ।
  
  

मैंने TryRoslyn पर चीजों का एक छोटा सा नमूना कार्यान्वयन किया: http://tinyurl.com/zej9yux

सौभाग्य से इसे जांचना आसान है। और अच्छी खबर यह है कि यह ठीक से काम करता है क्योंकि यह . है

हमारे पास int में रूपांतरण के लिए बस एक निहित ऑपरेटर होना चाहिए ताकि लोगों के पास वह अंतिम .Value कॉल न हो।

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

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryHashCombiner(int h1, int h2, int h3, int h4)
        {
            var h = new HashCode(h1).Combine(h2).Combine(h3).Combine(h4);
            return h.Value;
        }

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

कम्बाइन वास्तविक नाम है जो हैशिंग समुदाय afaik में उपयोग किया जाता है। और यह आपको एक स्पष्ट विचार देता है कि यह क्या कर रहा है।

@jamesqo बहुत सारे हैशिंग फ़ंक्शन हैं, हमें रेवेनडीबी के लिए 32 बिट, 64 बिट से 128 बिट तक के लिए बहुत तेज़ संस्करणों को लागू करना था (और हम अलग-अलग उद्देश्यों के लिए हर एक का उपयोग करते हैं)।

हम इस तरह के कुछ एक्स्टेंसिबल तंत्र के साथ इस डिजाइन में आगे सोच सकते हैं:

        internal interface IHashCode<T> where T : struct
        {
            T Combine(T h1, T h2);
        }

        internal struct RotateHashCode : IHashCode<int>, IHashCode<long>
        {
            long IHashCode<long>.Combine(long h1, long h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                ulong shift5 = ((ulong)h1 << 5) | ((ulong)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }

            int IHashCode<int>.Combine(int h1, int h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                uint shift5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }
        }

        internal struct HashCodeCombiner<T, W> where T : struct, IHashCode<W>
                                               where W : struct
        {
            private static T hasher;
            public W Value;

            static HashCodeCombiner()
            {
                hasher = new T();
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public HashCodeCombiner(W seed)
            {
                this.Value = seed;
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public HashCodeCombiner<T,W> Combine( W h1 )
            {
                Value = hasher.Combine(this.Value, h1);
                return this;
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryHashCombinerT(int h1, int h2, int h3, int h4)
        {
            var h = new HashCodeCombiner<RotateHashCode, int>(h1).Combine(h2).Combine(h3).Combine(h4);
            return h.Value;
        }

मुझे नहीं पता कि जेआईटी इसके लिए बहुत कष्टप्रद प्रोलॉग कोड क्यों बना रहा है। ऐसा नहीं होना चाहिए, शायद इसे अनुकूलित किया जा सकता है, हमें इसके लिए जेआईटी देवों से पूछना चाहिए। लेकिन बाकी के लिए आप एक भी निर्देश को बर्बाद किए बिना जितने चाहें उतने अलग-अलग कॉम्बिनर लागू कर सकते हैं। ऐसा कहने के बाद, यह विधि संभवतः संयोजकों की तुलना में वास्तविक हैश फ़ंक्शन के लिए अधिक उपयोगी है। cc @CarolEidt @AndyAyersMS

संपादित करें: एक ही हैशिंग अवधारणा छतरी के नीचे क्रिप्टो और गैर-क्रिप्टो हैश फ़ंक्शंस को संयोजित करने के लिए एक सामान्य तंत्र के लिए यहां ज़ोर से सोचना।

@jamesqo

यह बिल्डर पैटर्न के बाद एक परिवर्तनशील संरचना होने की आवश्यकता नहीं है

आह हाँ। उस मामले में मैं उस पैटर्न के साथ ठीक हूँ। यदि ऑपरेशन का कोई साइड इफेक्ट होता है तो मुझे आमतौर पर रिटर्निंग इंस्टेंस का पैटर्न पसंद नहीं है। यह विशेष रूप से बुरा है अगर एपीआई अपरिवर्तनीय WithXxx पैटर्न का पालन कर रहा है। इस मामले में हालांकि, पैटर्न अनिवार्य रूप से एक अपरिवर्तनीय डेटा संरचना है ताकि पैटर्न ठीक काम करे।

मुझे लगता है कि हम आपके और मेरे विचारों को थोड़ा जोड़ सकते हैं।

, तो किस बारे में:

``` सी#
सार्वजनिक संरचना हैशकोड
{
सार्वजनिक स्थैतिक हैशकोड बनाएँ(टी ओबीजे);

[Pure] public HashCode Combine(int hashCode);
[Pure] public HashCode Combine(long hashCode);
[Pure] public HashCode Combine<T>(T obj);
[Pure] public HashCode Combine(string text, StringComparison comparison);

public int Value { get; }

public static implicit operator int(HashCode hashCode);

}

This allows for code like this:

``` C#
public override int GetHashCode()
{
    return HashCode.Create(value1).Combine(value2);
}

साथ में यह भी:

``` सी#
वर हैशकोड = नया हैशकोड ()
.Combine(IsMainPage ? 1:0)
.Combine(ViewName, StringComparer.Ordinal)
.Combine(ControllerName, StringComparer.Ordinal)
.Combine(AreaName, StringComparer.Ordinal);

अगर (ViewLocationExpanderValues!= null)
{
foreach (ViewLocationExpanderValues ​​​​में var आइटम)
{
हैशकोड = हैशकोड। कॉम्बिनेशन (आइटम। की, स्ट्रिंगकॉमपेयर। ऑर्डिनल);
हैशकोड = हैशकोड। कॉम्बिन (आइटम। वैल्यू, स्ट्रिंगकॉमपेयर। ऑर्डिनल);
}
}

वापसी हैशकोड। मूल्य;
```

@terrajobst विचार:

1. Create<T> फ़ैक्टरी पद्धति को हटा दिया जाना चाहिए। अन्यथा, एक ही चीज़ को लिखने के 2 तरीके होंगे, HashCode.Create(_val) या new HashCode().Combine(_val) । साथ ही, Create / Combine लिए अलग-अलग नाम होने से अंतर-अनुकूल नहीं होगा क्योंकि यदि आप एक नया पहला फ़ील्ड जोड़ते हैं, तो आपको 2 पंक्तियों को बदलना होगा।
2. मुझे नहीं लगता कि एक स्ट्रिंग/स्ट्रिंग कॉम्पैरिसन को स्वीकार करने वाला अधिभार यहां है; HashCode का स्ट्रिंग्स से कोई लेना-देना नहीं है। इसके बजाय, शायद हमें स्ट्रिंग में GetHashCode(StringComparison) एपीआई जोड़ना चाहिए? (साथ ही वे सभी क्रमिक तुलनाएं हैं, जो string.GetHashCode का डिफ़ॉल्ट व्यवहार है।)
3. Value होने का क्या मतलब है, अगर int रूपांतरण के लिए पहले से ही एक निहित ऑपरेटर है? फिर, यह अलग-अलग लोगों को अलग-अलग चीजें लिखने के लिए प्रेरित करेगा।
4. हमें long अधिभार को एक नए प्रकार में स्थानांतरित करना होगा। HashCode केवल 32 बिट चौड़ा होगा; यह लंबे समय तक फिट नहीं हो सकता।
5. आइए कुछ अधिभार अहस्ताक्षरित प्रकार लेते हैं, क्योंकि वे हैशिंग में अधिक सामान्य हैं।

यहाँ मेरी प्रस्तावित एपीआई है:

public struct HashCode
{
    public HashCode Combine(int hash);
    public HashCode Combine(uint hash);
    public HashCode Combine<T>(T obj);

    public static implicit operator int(HashCode hashCode);
    public static implicit operator uint(HashCode hashCode);
}

public struct Int64HashCode
{
    public Int64HashCode Combine(long hash);
    public Int64HashCode Combine(ulong hash);

    public static implicit operator long(Int64HashCode hashCode);
    public static implicit operator ulong(Int64HashCode hashCode);
}

केवल इन विधियों के साथ, ASP.NET का उदाहरण अभी भी इस प्रकार लिखा जा सकता है

var hashCode = new HashCode()
    .Combine(IsMainPage ? 1 : 0)
    .Combine(ViewName)
    .Combine(ControllerName)
    .Combine(AreaName);

if (ViewLocationExpanderValues != null)
{
    foreach (var item in ViewLocationExpanderValues)
    {
        hashCode = hashCode.Combine(item.Key);
        hashCode = hashCode.Combine(item.Value);
    }
}

return hashCode;

@jamesqo

Value होने का क्या मतलब है, अगर int रूपांतरण के लिए पहले से ही एक निहित ऑपरेटर है? फिर, यह अलग-अलग लोगों को अलग-अलग चीजें लिखने के लिए प्रेरित करेगा।

ऑपरेटर ओवरलोड के लिए फ्रेमवर्क डिजाइन दिशानिर्देश कहते हैं:

प्रत्येक अतिभारित ऑपरेटर से मेल खाने वाले अनुकूल नामों के साथ विधियां प्रदान करने पर विचार करें।

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

विशेष रूप से, F# उन भाषाओं में से एक है जो निहित रूपांतरण ऑपरेटरों को लागू करना अजीब बनाता है।

साथ ही, मुझे नहीं लगता कि चीजों को करने का केवल एक ही तरीका महत्वपूर्ण है। मेरी राय में, एपीआई को सुविधाजनक बनाना अधिक महत्वपूर्ण है। अगर मैं कुछ मूल्यों के हैश कोड को जोड़ना चाहता हूं, तो मुझे लगता है कि HashCode.CombineHashCodes(value1, value2, value3) new HashCode().Combine(value1).Combine(value2).Combine(value3) तुलना में सरल, छोटा और समझने में आसान है।

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

@svick , अन्य भाषाओं के बारे में आपकी बात जो ऑपरेटरों का समर्थन नहीं करती है, वह वैध है। मैं उपज, चलो फिर Value जोड़ें।

मुझे नहीं लगता कि चीजों को करने का केवल एक ही तरीका होना इतना महत्वपूर्ण है।

क्या यह महत्वपूर्ण है। अगर कोई इसे एक तरह से करता है, और उस व्यक्ति के कोड को पढ़ता है जो इसे दूसरे तरीके से करता है, तो उसे Google को दूसरे तरीके से करना होगा।

अगर मैं सिर्फ कुछ मानों के हैश कोड को जोड़ना चाहता हूं, तो मुझे लगता है कि हैशकोड। कॉम्बिन हैशकोड्स (वैल्यू 1, वैल्यू 2, वैल्यू 3) नए हैशकोड () की तुलना में सरल, छोटा और समझने में आसान है। कॉम्बिनेशन (वैल्यू 1)। कॉम्बाइन (वैल्यू 2)। कॉम्बाइन ( मान 3)।

• एक स्थिर विधि के साथ समस्या यह है कि, चूंकि कोई params int[] अधिभार नहीं होगा,
• दूसरा रूप एक या दो बार देखने पर समझने में आसानी होगी। वास्तव में, आप तर्क दे सकते हैं कि यह अधिक पठनीय है, क्योंकि लंबवत रूप से श्रृंखलाबद्ध करना आसान है (और इस प्रकार जब कोई फ़ील्ड जोड़ा/निकाल दिया जाता है तो अंतर कम हो जाता है):

public override int GetHashCode()
{
    return new HashCode()
        .Combine(_field1)
        .Combine(_field2)
        .Combine(_field3)
        .Combine(_field4);
}

[@svick] मुझे नहीं लगता कि चीजों को करने का केवल एक ही तरीका महत्वपूर्ण है।

मुझे लगता है कि एक ही काम करने के तरीकों की संख्या को कम करना महत्वपूर्ण है क्योंकि यह भ्रम से बचा जाता है। साथ ही, हमारा लक्ष्य 100% ओवरलैपिंग मुक्त होना नहीं है यदि यह अन्य लक्ष्यों को प्राप्त करने में मदद करता है, जैसे कि खोज योग्यता, सुविधा, प्रदर्शन या पठनीयता। सामान्य तौर पर, हमारा लक्ष्य एपीआई के बजाय अवधारणाओं को कम करना है। उदाहरण के लिए, अलग-अलग शब्दावली के साथ कई अलग-अलग तरीकों की तुलना में एकाधिक अधिभार कम समस्याग्रस्त हैं।

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

एक अच्छा साइड इफेक्ट यह है कि यह बहुत समान दिखता है कि कैसे अपरिवर्तनीय डेटा संरचनाएं ढांचे में दिखती हैं। और एपीआई डिज़ाइन में हम लगभग किसी भी चीज़ पर स्थिरता का दृढ़ता से समर्थन करते हैं।

[@svick] अगर मैं सिर्फ कुछ मानों के हैश कोड को जोड़ना चाहता हूं, तो मुझे लगता है कि हैशकोड। कॉम्बिन हैशकोड्स (वैल्यू 1, वैल्यू 2, वैल्यू 3) नए हैशकोड () की तुलना में सरल, छोटा और समझने में आसान है। कॉम्बिनेशन (वैल्यू 1)। कॉम्बिनेशन (वैल्यू 2) )। गठबंधन (मान 3)।

मैं @jamesqo से सहमत

[@jamesqo] मुझे नहीं लगता कि एक स्ट्रिंग/स्ट्रिंग कॉम्पैरिसन को स्वीकार करने वाला अधिभार यहां है; हैशकोड का तार से कोई लेना-देना नहीं है

निष्पक्ष बिंदु। मैंने इसे इसलिए जोड़ा क्योंकि इसे @Eilon के कोड में संदर्भित किया गया था। अनुभव से मैं कहूंगा कि तार बहुत आम हैं। दूसरी ओर, मुझे यकीन नहीं है कि तुलना निर्दिष्ट करना है। आइए इसे अभी के लिए छोड़ दें।

[@jamesqo] हमें लंबे अधिभार को एक नए प्रकार में स्थानांतरित करना होगा। HashCode केवल 32 बिट चौड़ा होगा; यह लंबे समय तक फिट नहीं हो सकता।

ये एक अच्छा बिंदु है। क्या हमें long संस्करण की बिल्कुल भी आवश्यकता है? मैंने इसे केवल इसलिए छोड़ा है क्योंकि इसका ऊपर उल्लेख किया गया था और मैंने वास्तव में इसके बारे में नहीं सोचा था।

अब जब मैं हूं, ऐसा लगता है कि हमें केवल 32-बिट छोड़ना चाहिए क्योंकि यही .NET GetHashCode() के बारे में है। उस नस में, मुझे यकीन भी नहीं है कि हमें uint संस्करण जोड़ना चाहिए। यदि आप उस दायरे के बाहर हैशिंग का उपयोग करते हैं, तो मुझे लगता है कि लोगों को हमारे पास System.Security.Cryptography में अधिक सामान्य उद्देश्य हैशिंग एल्गोरिदम पर इंगित करना ठीक है।

```सी#
सार्वजनिक संरचना हैशकोड
{
सार्वजनिक स्थैतिक हैशकोड बनाएँ(टी ओबीजे);

[Pure] public HashCode Combine(int hashCode);
[Pure] public HashCode Combine<T>(T obj);

public int Value { get; }

public static implicit operator int(HashCode hashCode);

}
```

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

@terrajobst बहुत अलग प्रकार के हैशिंग एल्गोरिदम हैं, एक वास्तविक चिड़ियाघर। वास्तव में, शायद 70% डिज़ाइन द्वारा गैर-क्रिप्टोग्राफ़िक हैं। और शायद उनमें से आधे से अधिक 64+ बिट्स से निपटने के लिए डिज़ाइन किए गए हैं (सामान्य लक्ष्य 128/256 है)। यह कि ढांचे ने 32 बिट्स का उपयोग करने का निर्णय लिया है (मैं वहां नहीं गया हूं) क्योंकि उस समय x86 अभी भी एक बहुत बड़ा उपभोक्ता था और सभी जगह हैश का उपयोग किया जाता था, इसलिए कम हार्डवेयर पर प्रदर्शन सर्वोपरि था।

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

इसे int तक सीमित करना हमारे पास आज की तुलना में बेहतर नहीं है। अगर यह मेरी कॉल होती तो मैं डिजाइन टीम को यह देखने के लिए प्रेरित करता कि हम 128 और 256 वेरिएंट और विभिन्न हैश फ़ंक्शंस को कैसे समायोजित कर सकते हैं (भले ही हम आपकी उंगलियों के निशान के तहत मुझे न सोचने के विकल्प को फेंक दें)।

ओवरसिम्प्लीफिकेशन के कारण होने वाली समस्याएं कभी-कभी जटिल सामग्री से निपटने के लिए मजबूर होने पर पेश किए गए डिज़ाइन के मुद्दों से भी बदतर होती हैं। इतनी बड़ी डिग्री तक कार्यक्षमता को सरल बनाना क्योंकि डेवलपर्स को not being able to deal with having multiple options माना जाता है, आसानी से SIMD की वर्तमान स्थिति के मार्ग पर ले जा सकता है। अधिकांश प्रदर्शन जागरूक डेवलपर्स इसका उपयोग नहीं कर सकते हैं, और अच्छी तरह से हर कोई इसका उपयोग नहीं करेगा क्योंकि अधिकांश प्रदर्शन संवेदनशील अनुप्रयोगों से निपट नहीं रहे हैं जिनके पास ऐसे अच्छे थ्रूपुट लक्ष्य हैं।

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

साथ ही जैसे ही आपको 75000 से अधिक तत्वों से निपटना होता है, आपके पास टकराव होने की 50% संभावना होती है, और यह ज्यादातर परिदृश्यों में खराब है (और यह मान रहा है कि आपके पास एक अच्छी तरह से डिज़ाइन किया गया हैश फ़ंक्शन है)। यही कारण है कि 64 बिट्स और 128 बिट्स का उपयोग रनटाइम संरचनाओं की सीमाओं के बाहर किया जाता है।

int पर अटके डिज़ाइन के साथ हम केवल 2000 में मंडे अख़बार न होने के कारण होने वाली समस्याओं को कवर कर रहे हैं (इसलिए अब हर कोई अपनी खराब हैशिंग खुद लिखता है) लेकिन हम एक कदम भी आगे नहीं बढ़ेंगे। कला या तो।

चर्चा में यह मेरा 2 सेंट है।

@redknightlois , मुझे लगता है कि हम int हैश की सीमाओं को समझते हैं। लेकिन मैं @terrajobst से सहमत

जब तक आपको नहीं लगता कि 128 बिट्स में हैश संयोजन करना अभी भी फायदेमंद है और फिर int में कनवर्ट करें ताकि परिणाम GetHahsCode से वापस किया जा सके।

@KrzysztofCwalina मैं सहमत हूं कि यह दो अलग-अलग दृष्टिकोण हैं। एक तो 2000 की वजह से हुई समस्या को ठीक करना है; सामान्य हैशिंग समस्या से निपटने के लिए एक अलग है। यदि हम सभी सहमत हैं कि यह पूर्व के लिए एक समाधान है, तो चर्चा समाप्त हो गई है। हालांकि, "भविष्य" मील का पत्थर के लिए एक डिजाइन चर्चा के लिए मुझे लगता है कि यह कम हो जाएगा, ज्यादातर इसलिए कि हम यहां क्या करेंगे भविष्य की चर्चा को प्रभावित करेगा। यहां गलतियां करने से असर पड़ेगा।

@redknightlois , मैं निम्नलिखित का प्रस्ताव

@redknightlois

यहां गलतियां करने से असर पड़ेगा।

मुझे लगता है कि अगर भविष्य में हम और अधिक उन्नत परिदृश्यों का समर्थन करना चाहते हैं, तो हम इसे HashCode से अलग प्रकार में कर सकते हैं। यहां निर्णय वास्तव में उन मामलों को प्रभावित नहीं करना चाहिए।

मैंने इससे निपटने के लिए एक अलग मुद्दा बनाया।

@redknightlois : +1:। बीटीडब्ल्यू, आपने अपनी टिप्पणी संपादित करने से पहले जवाब दिया, लेकिन मैंने वास्तव में हैश को किसी भी प्रकार (int, long, दशमलव, आदि) के साथ काम करने और संरचना में कोर हैशिंग तर्क को अपनाने के आपके विचार (उपरोक्त) का प्रयास किया: https://github.com/jamesqo/HashApi (नमूना उपयोग यहां था)। लेकिन, दो सामान्य प्रकार के पैरामीटर होने के कारण बहुत जटिल हो गए, और जब मैंने एपीआई का उपयोग करने की कोशिश की तो संकलक प्रकार का अनुमान काम नहीं कर रहा था। तो हाँ, अभी के लिए एक अलग मुद्दे में अधिक उन्नत हैशिंग करना एक अच्छा विचार है।

@terrajobst एपीआई लगभग तैयार लगता है, लेकिन 1 या 2 और चीजें हैं जिन्हें मैं बदलना चाहता हूं।

• मैं शुरू में स्थिर फ़ैक्टरी विधि नहीं चाहता था, क्योंकि HashCode.Create(x) का प्रभाव new HashCode().Combine(x) । लेकिन, मैंने इसके बारे में अपना विचार बदल दिया है क्योंकि इसका मतलब है कि 1 अतिरिक्त हैश। इसके बजाय, हम क्यों नाम बदलने नहीं है Create करने के लिए Combine ? ऐसा लगता है कि पहले फ़ील्ड के लिए एक चीज़ टाइप करना और दूसरे फ़ील्ड के लिए दूसरा टाइप करना थोड़ा परेशान है।
• मुझे लगता है कि हमें HashCode को IEquatable<HashCode> लागू करना चाहिए और कुछ समानता ऑपरेटरों को लागू करना चाहिए। यदि आपको कोई आपत्ति हो तो बेझिझक मुझे बताएं।

(उम्मीद है) अंतिम प्रस्ताव:

public struct HashCode : IEquatable<HashCode>
{
    public static HashCode Combine(int hash);
    public static HashCode Combine<T>(T obj);

    public HashCode Combine(int hash);
    public HashCode Combine<T>(T obj);

    public int Value { get; }

    public static implicit operator int(HashCode hashCode);

    public static bool operator ==(HashCode left, HashCode right);
    public static bool operator !=(HashCode left, HashCode right);

    public override bool Equals(object obj);
    public override bool Equals(HashCode other);
    public override int GetHashCode();
}

// Usage:

public override int GetHashCode()
{
    return HashCode
        .Combine(_field1)
        .Combine(_field2)
        .Combine(_field3)
        .Combine(_field4);
}

@terrajobst ने कहा:

निष्पक्ष बिंदु। मैंने इसे इसलिए जोड़ा क्योंकि इसे @Eilon के कोड में संदर्भित किया गया था। अनुभव से मैं कहूंगा कि तार बहुत आम हैं। दूसरी ओर, मुझे यकीन नहीं है कि तुलना निर्दिष्ट करना है। आइए इसे अभी के लिए छोड़ दें।

यह वास्तव में बहुत महत्वपूर्ण है: स्ट्रिंग्स के लिए हैश बनाने में अक्सर उस स्ट्रिंग के उद्देश्य को ध्यान में रखना शामिल होता है, जिसमें इसकी संस्कृति और इसकी केस-संवेदनशीलता दोनों शामिल होती है। StringComparer प्रति तुलना तुलना के बारे में नहीं है, बल्कि विशिष्ट GetHashCode कार्यान्वयन प्रदान करने के बारे में है जो संस्कृति/केस-जागरूक हैं।

इस एपीआई के बिना, आपको कुछ अजीब करना होगा जैसे:

HashCode.Combine(str1.ToLowerInvariant()).Combine(str2.ToLowerInvariant())

और वह आवंटन से भरा हुआ है, खराब संस्कृति-संवेदनशीलता पैटर्न आदि का पालन करता है।

@Eilon ऐसे मामले में मैं उम्मीद करता हूं कि कोड को स्पष्ट रूप से string.GetHashCode(StringComparison comparison) कॉल करना चाहिए जो कि संस्कृति/मामला-जागरूक है और परिणाम को int में Combine ।

c# HashCode.Combine(str1.GetHashCode(StringComparer.Ordinal)).Combine(...)

@Eilon , आप बस StringComparer.InvariantCultureIgnoreCase.GetHashCode का उपयोग कर सकते हैं।

आवंटन के मामले में वे निश्चित रूप से बेहतर हैं, लेकिन वे कॉल देखने में सुंदर नहीं हैं ... हमारे पास पूरे ASP.NET का उपयोग है जहां हैश को संस्कृति/केस-अवेयर स्ट्रिंग्स को शामिल करने की आवश्यकता है।

पर्याप्त रूप से, ऊपर बताई गई सभी बातों को मिलाकर, इस आकार के बारे में कैसा होगा:

``` सी#
नेमस्पेस सिस्टम
{
सार्वजनिक संरचना हैशकोड: IEquatable
{
सार्वजनिक स्थैतिक हैशकोड कम्बाइन (इंट हैश);
सार्वजनिक स्थैतिक हैशकोड संयोजन(टी ओबीजे);
सार्वजनिक स्थैतिक हैशकोड कम्बाइन (स्ट्रिंग टेक्स्ट, स्ट्रिंग तुलना तुलना);

    public HashCode Combine(int hash);
    public HashCode Combine<T>(T obj);
    public HashCode Combine(string text, StringComparison comparison);

    public int Value { get; }

    public static implicit operator int(HashCode hashCode);

    public static bool operator ==(HashCode left, HashCode right);
    public static bool operator !=(HashCode left, HashCode right);

    public override bool Equals(object obj);
    public override bool Equals(HashCode other);
    public override int GetHashCode();
}

}

// उपयोग:

सार्वजनिक ओवरराइड int GetHashCode ()
{
वापसी HashCode.Combine(_field1)
.Combine(_field2)
.Combine(_field3)
.Combine(_field4);
}
```

इसे भेज दो! :-)

@terrajobst _Hold on--_ Combine(string, StringComparison) केवल एक विस्तार विधि के रूप में लागू नहीं किया जा सकता है?

public static class HashCodeExtensions
{
    public static HashCode Combine(this HashCode hashCode, string text, StringComparison comparison)
    {
        switch (comparison)
        {
            case StringComparison.Ordinal:
                return HashCode.Combine(StringComparer.Ordinal.GetHashCode(text));
            case StringComparison.OrdinalIgnoreCase:
                ...
        }
    }
}

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

( संपादित करें: इसके अलावा System.Numerics शायद एक बेहतर नामस्थान है, जब तक कि हमारे पास संग्रह में हैश-संबंधित प्रकार नहीं हैं। जेनेरिक आज जिसके बारे में मुझे जानकारी नहीं है।)

एलजीटीएम। मैं विस्तार जाऊंगा।

हाँ, यह एक विस्तार विधि हो सकती है, लेकिन यह किस समस्या का समाधान करती है?

@terrajobst

हाँ, यह एक विस्तार विधि हो सकती है, लेकिन यह किस समस्या का समाधान करती है?

मैं ASP.NET कोड में सुझाव दे रहा था। यदि उनके उपयोग के मामले में यह सामान्य है, तो यह ठीक है, लेकिन यह अन्य पुस्तकालयों/ऐप्स के लिए सच नहीं हो सकता है। यदि बाद में पता चलता है कि यह काफी सामान्य है, तो हम हमेशा पुनर्मूल्यांकन कर सकते हैं और इसे एक अलग प्रस्ताव में जोड़ने का निर्णय ले सकते हैं।

Mhhh यह वैसे भी कोर है। एक बार परिभाषित होने के बाद यह वैसे भी हस्ताक्षर का हिस्सा होगा। टिप्पणी स्क्रैप करें। यह जैसा है ठीक है।

विस्तार विधियों का उपयोग उन मामलों के लिए उपयोगी है जहां:

1. यह एक मौजूदा प्रकार है जिसे हम इस प्रकार के अपडेट को शिप किए बिना बढ़ाना चाहते हैं
2. लेयरिंग मुद्दों को हल करें
3. सुपर कॉमन एपीआई को बहुत कम इस्तेमाल होने वाले एपीआई से अलग करें।

मुझे नहीं लगता कि (1) या (2) यहां लागू होते हैं। (3) केवल तभी मदद करेगा जब हम कोड को HashCode से भिन्न असेंबली में ले जाएंगे या यदि हम इसे किसी भिन्न नामस्थान पर ले जाएंगे। मैं तर्क दूंगा कि तार काफी सामान्य हैं कि यह इसके लायक नहीं है। वास्तव में, मैं यह भी तर्क दूंगा कि वे इतने सामान्य हैं कि उन्हें प्रथम श्रेणी के रूप में व्यवहार करना कृत्रिम रूप से उन्हें एक विस्तार प्रकार पर अलग करने की कोशिश करने से अधिक समझ में आता है।

@terrajobst , स्पष्ट होने के लिए मैं सुझाव दे रहा था कि string API को पूरी तरह से हटा दें, और स्ट्रिंग्स के लिए अपनी स्वयं की एक्सटेंशन विधि लिखने के लिए इसे ASP.NET पर छोड़ दें।

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

हां, लेकिन किसी के लिए स्ट्रिंग का गैर-क्रमिक हैश कोड प्राप्त करना कितना आम है, जो एकमात्र परिदृश्य है जो मौजूदा Combine<T> अधिभार का ख्याल नहीं रखता है? (उदाहरण के लिए कोई है जो StringComparer.CurrentCulture.GetHashCode को उनके ओवरराइड में कॉल करता है?) मैं गलत हो सकता हूं, लेकिन मैंने कई लोगों को नहीं देखा है।

इस पर पुशबैक के लिए खेद है; यह सिर्फ इतना है कि एक बार एपीआई जोड़ने के बाद वापस नहीं जा रहा है।

हां, लेकिन किसी के लिए स्ट्रिंग का गैर-क्रमिक हैश कोड प्राप्त करना कितना सामान्य है?

मैं पक्षपाती हो सकता हूं, लेकिन केस इनवेरिएंस काफी लोकप्रिय है। निश्चित रूप से, कई (यदि कोई हैं) संस्कृति-विशिष्ट हैश-कोड की देखभाल नहीं करते हैं, लेकिन हैश-कोड जो आवरण को अनदेखा करते हैं, मैं पूरी तरह से देख सकता हूं - और ऐसा लगता है कि @Eilon बाद में है (जो StringComparison.OrdinalIgnoreCase )।

इस पर पुशबैक के लिए खेद है; यह सिर्फ इतना है कि एक बार एपीआई जोड़ने के बाद वापस नहीं जा रहा है।

कोई मज़ाक नहीं 😈 सहमत, लेकिन भले ही एपीआई का उतना उपयोग न किया गया हो, यह उपयोगी है और इससे कोई नुकसान नहीं होता है।

@terrajobst ठीक है, इसे जोड़ें: +1: अंतिम अंक: मैंने ऊपर इसका उल्लेख किया है, लेकिन क्या हम संग्रह के बजाय नेमस्पेस न्यूमेरिक्स बना सकते हैं। जेनेरिक? अगर हम भविष्य में और अधिक हैशिंग-संबंधित प्रकार जोड़ते हैं जैसे

मुझे यह पसंद है। मैं

मुझे नहीं लगता हैशिंग वैचारिक रूप से संग्रह में आता है। System.Runtime के बारे में क्या?

मैं वही सुझाव देने जा रहा था, या यहां तक ​​​​कि System. यह न्यूमेरिक्स भी नहीं है।

@karelz , System.Runtime काम कर सकता है। @redknightlois सिस्टम सुविधाजनक होगा, क्योंकि संभावना है कि आप पहले ही उस नेमस्पेस को आयात कर चुके हैं। डुनो अगर यह उचित होगा, हालांकि (फिर से, यदि अधिक हैशिंग प्रकार जोड़े जाते हैं)।

हमें इसे System.Runtime में नहीं रखना चाहिए क्योंकि यह गूढ़ और काफी विशिष्ट मामलों के लिए है। मैंने @KrzysztofCwalina से बात की और हम दोनों को लगता है कि यह दोनों में से एक है:

• System
• System.Collections.*

हम दोनों System ओर झुकते हैं।

अगर हमें System लिए जाने का औचित्य है तो मैं एक औचित्य का प्रयास कर सकता हूं। हमने HashCode को object.GetHashCode() कार्यान्वयन में सहायता के लिए बनाया है, यह उचित लगता है कि दोनों नामस्थान साझा करेंगे।

@terrajobst मुझे लगता है कि System नामस्थान होना चाहिए। चलो :शिपिट:

विवरण में API युक्ति को अपडेट किया गया।

[@redknightlois] अगर हमें System लिए जाने का औचित्य चाहिए तो मैं एक औचित्य का प्रयास कर सकता हूं। हमने HashCode को object.GetHashCode() कार्यान्वयन में सहायता के लिए बनाया है, यह उचित लगता है कि दोनों नामस्थान साझा करेंगे।

यही कारण था कि @KrzysztofCwalina और मैंने भी इसका इस्तेमाल किया। बेचा!

@jamesqo

मुझे लगता है कि आप पीआर को कार्यान्वयन के साथ भी प्रदान करना चाहते हैं?

@terrajobst हाँ, निश्चित रूप से। इसकी समीक्षा करने के लिए समय निकालने के लिए धन्यवाद!

हाँ निश्चित रूप से।

मिठाई। उस स्थिति में मैं इसे आपको सौंप दूंगा। यह आपके साथ अच्छा है @karelz?

इसकी समीक्षा करने के लिए समय निकालने के लिए धन्यवाद!

एपीआई आकार पर हमारे साथ काम करने के लिए समय निकालने के लिए धन्यवाद। आगे और पीछे जाना एक दर्दनाक प्रक्रिया हो सकती है। हम आपके धैर्य की अत्यधिक सराहना करते हैं!

और मैं ASP.NET कोर कार्यान्वयन को हटाने और इसके बजाय इसका उपयोग करने की आशा कर रहा हूं

सार्वजनिक स्थैतिक हैशकोड कम्बाइन (स्ट्रिंग टेक्स्ट, स्ट्रिंग तुलना तुलना);
सार्वजनिक हैशकोड कम्बाइन (स्ट्रिंग टेक्स्ट, स्ट्रिंग तुलना तुलना);

निट: पर तरीकों String कि ले StringComparison (जैसे Equals , Compare , StartsWith , EndsWith , आदि ।) पैरामीटर के नाम के रूप में comparisonType का उपयोग करें, न कि comparison । क्या पैरामीटर को comparisonType नाम दिया जाना चाहिए और साथ ही सुसंगत होना चाहिए?

@justinvp , जो स्ट्रिंग के तरीकों में नामकरण दोष की तरह लगता है; Type बेमानी है। मुझे नहीं लगता कि हमें पुराने एपीआई के साथ "उदाहरण का पालन करें" के लिए नए एपीआई में पैरामीटर नामों को अधिक वर्बोज़ बनाना चाहिए।

एक अन्य डेटा बिंदु के रूप में, xUnit ने comparisonType का भी उपयोग करना चुना।

@justinvp आपने मुझे आश्वस्त किया है। अब जब मैं इसके बारे में सहज रूप से सोचता हूं, "केस-असंवेदनशील" या "संस्कृति-निर्भर" तुलना का एक 'प्रकार' है। मैं नाम बदल दूंगा।

मैं इसके आकार के साथ ठीक हूं, लेकिन StringComparison के संबंध में, एक संभावित विकल्प:

शामिल न करें:

``` सी#
सार्वजनिक स्थैतिक हैशकोड कम्बाइन (स्ट्रिंग टेक्स्ट, स्ट्रिंग तुलना तुलना);
सार्वजनिक हैशकोड कम्बाइन (स्ट्रिंग टेक्स्ट, स्ट्रिंग तुलना तुलना);

Instead, add a method:

``` C#
public class StringComparer
{
    public static StringComparer FromComparison(StringComparison comparison);
    ...
}

फिर लिखने के बजाय:

``` सी#
सार्वजनिक ओवरराइड int GetHashCode ()
{
वापसी HashCode.Combine(_field1)
.Combine(_field2)
.Combine(_field3)
.Combine(_field4, _comparison);
}

you write:

``` C#
public override int GetHashCode()
{
    return HashCode.Combine(_field1)
                   .Combine(_field2)
                   .Combine(_field3)
                   .Combine(StringComparer.FromComparison(_comparison).GetHashCode(_field4));
}

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

C# public override int GetHashCode() { return HashCode.Combine(_field1) .Combine(_field2) .Combine(_field3) .Combine(_comparer.GetHashCode(_field4)); }

@stephentoub , FromComparison एक अच्छे विचार की तरह लगता है। मैंने वास्तव में string.GetHashCode(StringComparison) एपीआई जोड़ने के लिए धागे में ऊपर की ओर प्रस्तावित किया है, जो आपके उदाहरण को और भी आसान बनाता है (गैर-शून्य स्ट्रिंग मानते हुए):

public override int GetHashCode()
{
    return HashCode.Combine(_field1)
                   .Combine(_field2)
                   .Combine(_field3)
                   .Combine(_field4.GetHashCode(_comparison));
}

@Elion ने कहा कि हालांकि इसमें बहुत अधिक कॉल शामिल हैं।

(संपादित करें: आपके एपीआई के लिए एक प्रस्ताव बनाया।)

मैं स्ट्रिंग के लिए HashCode पर 2 विशेष विधियों को जोड़ना भी नापसंद करता हूं।
@Eilon आपने उल्लेख किया है कि पैटर्न का उपयोग ASP.NET कोर में ही किया जाता है। आपको क्या लगता है कि बाहरी डेवलपर इसका कितना उपयोग करेंगे?

@jamesqo डिजाइन चलाने के लिए धन्यवाद! जैसा कि @terrajobst ने कहा, हम आपकी मदद और धैर्य की सराहना करते हैं। मौलिक छोटे एपीआई को कभी-कभी पुनरावृति करने में कुछ समय लग सकता है :)।

आइए देखें कि हम एपीआई फीडबैक के इस अंतिम भाग के साथ कहां उतरते हैं, फिर हम कार्यान्वयन के साथ आगे बढ़ सकते हैं।

क्या कोई होना चाहिए:

C# public static HashCode Combine<T>(T obj, IEqualityComparer<T> cmp);

?

(क्षमा करें अगर वह पहले ही खारिज कर दिया गया था और मैं इसे यहां याद कर रहा हूं)।

@stephentoub ने कहा:

लिखो:

c# public override int GetHashCode() { return HashCode.Combine(_field1) .Combine(_field2) .Combine(_field3) .Combine(StringComparer.FromComparison(_comparison).GetHashCode(_field4)); }

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

खैर, यह थोड़ा लंबा नहीं है, यह बहुत लंबे समय तक चलने जैसा है, और इसमें शून्य खोज योग्यता है।

इस विधि को जोड़ने का प्रतिरोध क्या है? यदि यह उपयोगी है, स्पष्ट रूप से सही ढंग से कार्यान्वित किया जा सकता है, इसमें कोई अस्पष्टता नहीं है कि यह क्या करता है, इसे क्यों न जोड़ें?

अतिरिक्त स्थिर सहायक/रूपांतरण विधि ठीक है - हालांकि मुझे यकीन नहीं है कि मैं इसका उपयोग करूंगा - लेकिन सुविधा विधियों की कीमत पर क्यों?

सुविधाजनक तरीकों की कीमत पर क्यों?

क्योंकि यह मेरे लिए स्पष्ट नहीं है कि यहां सुविधा विधियों की वास्तव में आवश्यकता है। मुझे लगता है कि ASP.NET इसे विभिन्न स्थानों पर करता है। कितनी जगह? और उनमें से कितने स्थानों में यह वास्तव में एक चर StringComparison है जो आपके पास एक ज्ञात मूल्य के बजाय है? इस मामले में आपको मेरे द्वारा बताए गए सहायक की भी आवश्यकता नहीं है और बस कर सकते हैं:

``` सी#
.Combine(StringComparer.InvariantCulture.GetHashCode(_field4))

which in no way seems onerous to me or any more undiscoverable than knowing about StringComparison and doing:

``` C#
.Combine(_field4, StringComparison.InvariantCulture);

और वास्तव में तेज़ है, क्योंकि हमें ठीक वही काम करने के लिए कंबाइन के अंदर शाखा लगाने की ज़रूरत नहीं है जो देव लिख सकता था। क्या अतिरिक्त कोड इतनी असुविधा है कि उस एक मामले के लिए विशेष अधिभार जोड़ने लायक है? StringComparer के लिए अधिभार क्यों नहीं? EqualityComparer के लिए अधिभार क्यों नहीं? Func<T, int> लेने वाले ओवरलोड क्यों नहीं? किसी बिंदु पर आप रेखा खींचते हैं और कहते हैं, "यह अधिभार जो मूल्य प्रदान करता है वह इसके लायक नहीं है", क्योंकि हम जो कुछ भी जोड़ते हैं वह लागत पर आता है, चाहे वह रखरखाव की लागत हो, कोड आकार की लागत, जो कुछ भी लागत , और अगर देव को वास्तव में इस मामले की आवश्यकता है, तो देव के लिए कम विशिष्ट मामलों को संभालने के लिए यह बहुत कम अतिरिक्त कोड है। तो मैं सुझाव दे रहा था कि रेखा खींचने का सही स्थान बाद के बजाय इन अधिभारों से पहले है (लेकिन जैसा कि मैंने अपनी पिछली प्रतिक्रिया की शुरुआत में कहा था, "मैं इसके आकार के साथ ठीक हूं", और एक विकल्प का सुझाव दे रहा था) .

यहाँ मैंने जो खोज की है: https://github.com/search?p=2&q=user%3Aaspnet+hashcodecombiner&type=Code&utf8=%E2%9C%93

~ 100 मैचों में से, यहां तक ​​​​कि पहले कुछ पृष्ठों से भी लगभग हर उपयोग के मामले में तार होते हैं, और कई मामलों में विभिन्न प्रकार की स्ट्रिंग तुलनाओं का उपयोग किया जाता है:

1. सामान्य: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/TagHelperAttribute.cs#L46Comparer
2. साधारण + इग्नोरकेस: https://github.com/aspnet/Razor/blob/bdbb854bdbde260b3c70f565a93ebbb185a7c5a7/src/Microsoft.AspNetCore.Razor/Compilation/TagHelpers/TagHelperRequiredAttributeDescriptor
3. सामान्य: https://github.com/aspnet/Razor/blob/bdbb854bdbde260b3c70f565a93ebbb185a7c5a7/src/Microsoft.AspNetCore.Razor/Chunks/Generators/AttributeBlockChunkGenerator.cs#L58
4. सामान्य: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/TagHelperDesignTimeDescript#LComparer.cs
5. सामान्य: https://github.com/aspnet/Razor/blob/dbcb6901209859e471c9aa978912cf7d6c178668/src/Microsoft.AspNetCore.Razor.Evolution/Legacy/AttributeBlockChunkGenerator.cs#L56
6. सामान्य: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/CaseSensitiveTagHelper.cs#L62Comparer
7. साधारण + इग्नोरकेस: https://github.com/aspnet/dnx/blob/bebc991012fe633ecac69675b2e892f568b927a5/src/Microsoft.Dnx.Tooling/NuGet/Core/PackageSource/PackageSource.cs#L107
8. सामान्य: https://github.com/aspnet/Razor/blob/bdbb854bdbde260b3c70f565a93ebbb185a7c5a7/src/Microsoft.AspNetCore.Razor/Tokenizer/Symbols/SymbolBase.cs#L52
9. सामान्य: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/CaseSensitiveTagHelperAttribute
10. सामान्य: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/TagHelperAttributeComparerDesignTimeDescriptor

(और दर्जनों अन्य।)

तो ऐसा लगता है कि निश्चित रूप से ASP.NET कोर कोडबेस के भीतर यह एक अत्यंत सामान्य पैटर्न है। बेशक मैं किसी अन्य सिस्टम से बात नहीं कर सकता।

~100 मैचों में से

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

``` सी#
.Combine(Name, StringComparison.OrdinalIgnoreCase)

``` C#
.Combine(StringComparer.OrdinalIgnoreCase.GetHashCode(Name))

? यह "वाया सुपर लंबा" नहीं है और यह अधिक कुशल है, जब तक कि मुझे कुछ याद नहीं आ रहा है।

वैसे भी, जैसा कि मैंने कहा है, मैं बस सुझाव दे रहा हूं कि हम वास्तव में विचार करें कि ये अधिभार आवश्यक हैं या नहीं। यदि अधिकांश लोग मानते हैं कि वे हैं, और हम केवल अपने स्वयं के ASP.NET कोडबेस पर विचार नहीं कर रहे हैं, ठीक है।

संबंधित, हम किस व्यवहार के लिए अशक्त इनपुट की योजना बना रहे हैं? इंट == 0 के बारे में क्या? मैं स्ट्रिंग अधिभार के लिए और अधिक लाभ देखना शुरू कर सकता हूं यदि हम नल को पारित करने की अनुमति देते हैं, जैसा कि मेरा मानना ​​​​है कि StringComparer.GetHashCode आम तौर पर एक शून्य इनपुट के लिए फेंकता है, इसलिए यदि यह वास्तव में आम है, तो कॉलर के पास यह अधिक बोझिल होने लगता है विशेष मामले के लिए शून्य। लेकिन इसके बाद यह भी सवाल उठता है कि जब शून्य प्रदान किया जाता है तो व्यवहार क्या होगा। क्या किसी अन्य मान के साथ हैश कोड में 0 मिलाया गया है? क्या इसे एक एनओपी के रूप में माना जाता है और हैशकोड अकेला छोड़ दिया जाता है?

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

दरअसल, मेरा वोट ASP.NET Core के कोडबेस के नजरिए से आता है, जहां एक ओवरलोड जो कि स्ट्रिंग-अवेयर है, बहुत मददगार होगा। लाइन-लेंथ के बारे में चीजें वास्तव में मेरी मुख्य चिंता नहीं थीं, बल्कि खोज योग्यता के बारे में थीं।

यदि सिस्टम में एक स्ट्रिंग-अवेयर ओवरलोड उपलब्ध नहीं था, तो हम केवल ASP.NET कोर में एक आंतरिक एक्सटेंशन विधि जोड़ेंगे और उसका उपयोग करेंगे।

यदि सिस्टम में एक स्ट्रिंग-अवेयर ओवरलोड उपलब्ध नहीं था, तो हम केवल ASP.NET कोर में एक आंतरिक एक्सटेंशन विधि जोड़ेंगे और उसका उपयोग करेंगे।

मुझे लगता है कि यह अभी के लिए एक अच्छा समाधान होगा, जब तक कि हम अधिक सबूत नहीं देखते कि इस तरह के एपीआई की सामान्य रूप से आवश्यकता होती है, वह भी ASP.NET कोर कोड बेस के बाहर।

मेरा कहना है कि मुझे string अधिभार को हटाने में मूल्य दिखाई नहीं दे रहा है। यह किसी भी जटिलता को कम नहीं करता है, यह कोड और अधिक कुशल बनाने नहीं करता है, और यह हमें इस तरह के एक विधि उपलब्ध कराने के रूप में अन्य क्षेत्रों में सुधार करने से नहीं रोकता है कि रिटर्न एक StringComparer एक से StringComparison । सिंटेक्टिक शुगर _does_ मायने रखती है, क्योंकि .NET हमेशा से कॉमन केस को आसान बनाने के बारे में रहा है। हम डेवलपर को सही काम करने और सफलता के गड्ढे में गिरने के लिए भी मार्गदर्शन करना चाहते हैं।

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

1. हम @Eilon जैसे परिदृश्यों को बहुत आसान बनाते हैं।
2. हम इसे खोजने योग्य बनाते हैं कि स्ट्रिंग्स की तुलना पर विचार करना महत्वपूर्ण है, विशेष रूप से केसिंग।

हमें यह भी विचार करने की आवश्यकता है कि ऊपर वर्णित विस्तार विधि @Eilon जैसे सामान्य बॉयलरप्लेट

हालांकि, अगर प्राथमिक चिंता विशेष आवरण string बारे में है, तो इसके बारे में कैसे:

``` सी#
सार्वजनिक संरचना हैशकोड: IEquatable
{
सार्वजनिक हैशकोड गठबंधन(टी ओबीजे, आईईक्वालिटी कंपेयररतुलनाकर्ता);
}

// उपयोग
वापसी HashCode.Combine(_numberField)
.Combine(_stringField, StringComparer.OrdinalIgnoreCase);
```

@terrajobst , आपका समझौता एक चतुर है। मुझे पसंद है कि अब आपको GetHashCode स्पष्ट रूप से कॉल करने की आवश्यकता नहीं है या कस्टम तुलनाकर्ता के साथ कोष्ठक के एक अतिरिक्त सेट को घोंसला बनाना है।

(संपादित करें: मुझे लगता है कि मुझे वास्तव में इसका श्रेय @JonHanna को देना चाहिए क्योंकि उन्होंने पहले धागे में इसका उल्लेख किया था? )

@ जोनहन्ना हां, हम 0 के रूप में हैश नल इनपुट भी जा रहे हैं।

यहां बातचीत में बाधा डालने के लिए खेद है। लेकिन, मुझे नया प्रकार कहां रखना चाहिए? @mellinoe @ericstj @weshaggard , क्या आप सुझाव देते हैं कि मैं इस प्रकार के लिए एक नया असेंबली/पैकेज System.HashCode , या क्या मुझे इसे मौजूदा असेंबली जैसे System.Runtime.Extensions जोड़ना चाहिए? धन्यवाद।

हमने हाल ही में .NET कोर में असेंबली लेआउट को काफी हद तक दोबारा बदल दिया है; मैं इसे वहां रखने का सुझाव देता हूं जहां ठोस तुलनाकर्ता रहते हैं, जो System.Runtime.Extensions इंगित करते हैं।

@weshaggard?

@terrajobst प्रस्ताव के बारे में ही, मुझे अभी पता चला है कि हम दोनों स्थिर और उदाहरण ओवरलोड Combine नाम नहीं दे सकते, दुर्भाग्य से। मैं

संकलक त्रुटि में निम्नलिखित परिणाम होते हैं क्योंकि उदाहरण और स्थिर विधियों के समान नाम नहीं हो सकते हैं:

using System;
using System.Collections.Generic;

public struct HashCode
{
    public void Combine(int i)
    {
    }

    public static void Combine(int i)
    {
    }
}

अब हमारे पास 2 विकल्प हैं:

• Create , Seed , आदि जैसे कुछ अलग करने के लिए स्थिर अधिभार का नाम बदलें।
• स्थिर अधिभार को किसी अन्य स्थिर वर्ग में ले जाएं:

public static class Hash
{
    public static HashCode Combine(int hash);
}

public struct HashCode
{
    public HashCode Combine(int hash);
}

// Usage:
return Hash.Combine(_field1)
           .Combine(_field2)
           .Combine(_field3);

मैं दूसरे के प्रति तरजीही हूँ। यह दुर्भाग्यपूर्ण है कि हमें इस मुद्दे पर काम करना है, लेकिन... विचार?

तर्क को 2 प्रकारों में अलग करना मेरे लिए अजीब लगता है - HashCode का उपयोग करने के लिए आपको कनेक्शन बनाना होगा और इसके बजाय Hash वर्ग से शुरू करना होगा।

मैं इसके बजाय Create विधि (या Seed या Init )
मैं नो-आर्ग ओवरलोड भी जोड़ूंगा HashCode.Create().Combine(_field1).Combine(_field2) ।

@karelz , मुझे नहीं लगता कि अगर यह वही नाम नहीं है तो हमें फ़ैक्टरी विधि जोड़नी चाहिए। हमें केवल पैरामीटर रहित कंस्ट्रक्टर की पेशकश करनी चाहिए, new , क्योंकि यह अधिक प्राकृतिक है। इसके अलावा, ई लोगों को new HashCode().Combine लिखने से नहीं रोक सकता क्योंकि यह एक संरचना है।

public override int GetHashCode()
{
    return new HashCode()
        .Combine(_field1)
        ...
}

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

प्रस्तावित एपीआई (अद्यतन युक्ति):

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
        public HashCode Combine(int hash);
        public HashCode Combine<T>(T obj);
        public HashCode Combine<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public override bool Equals(object obj);
        public override bool Equals(HashCode other);
        public override int GetHashCode();
    }
}

@redknightlois @JonHanna @stephentoub @Eilon लिए, आपको फ़ैक्टरी विधि डिफ़ॉल्ट निर्माता का उपयोग कर बनाम पर एक राय है? मुझे पता चला कि संकलक स्थिर Combine अधिभार की अनुमति नहीं देता है क्योंकि यह उदाहरण विधियों के साथ संघर्ष करता है, इसलिए हमारे पास या तो विकल्प है

HashCode.Create(field1).Combine(field2) // ...

// or, using default constructor

new HashCode().Combine(field1).Combine(field2) // ...

पहले का फायदा यह है कि यह थोड़ा टेसर है। दूसरे का लाभ यह है कि इसका लगातार नामकरण होगा इसलिए आपको पहले क्षेत्र के लिए कुछ अलग लिखने की आवश्यकता नहीं है।

एक और संभावना दो अलग-अलग प्रकार की है, एक Combine फैक्ट्री के साथ, एक Combine इंस्टेंस के साथ (या पहले प्रकार पर एक्सटेंशन के रूप में दूसरा)।

मुझे यकीन नहीं है कि मैं कौन सा टीबीएच पसंद करूंगा।

@ जोनहन्ना , इंस्टेंस ओवरलोड के साथ आपका दूसरा विचार विस्तार विधियों के साथ बहुत अच्छा लगता है। उस ने कहा, उस मामले में hc.Combine(obj) स्थिर अधिभार पर लेने की कोशिश करता है: TryRoslyn ।

मैंने ऊपर कुछ टिप्पणियों के प्रवेश बिंदु के रूप में एक स्थिर वर्ग रखने का प्रस्ताव दिया, जो मुझे याद दिलाता है ... @karelz , आपने कहा

तर्क को 2 प्रकारों में अलग करना मेरे लिए अजीब लगता है - हैशकोड का उपयोग करने के लिए आपको कनेक्शन बनाना होगा और इसके बजाय हैश क्लास से शुरू करना होगा।

लोगों को क्या संबंध बनाना होगा? क्या हम उन्हें पहले Hash परिचित नहीं कराएंगे, और फिर वहां से वे HashCode ? मुझे नहीं लगता कि एक नया स्थिर वर्ग जोड़ना कोई समस्या होगी।

तर्क को 2 प्रकारों में अलग करना मेरे लिए अजीब लगता है - हैशकोड का उपयोग करने के लिए आपको कनेक्शन बनाना होगा और इसके बजाय हैश क्लास से शुरू करना होगा।

हम शीर्ष-स्तरीय प्रकार HashCode रख सकते हैं और केवल संरचना को घोंसला बना सकते हैं। यह एपीआई के "प्रवेश बिंदु" को एक शीर्ष-स्तरीय प्रकार में रखते हुए वांछित उपयोग की अनुमति देगा, उदाहरण के लिए:

``` सी#
नेमस्पेस सिस्टम
{
सार्वजनिक स्थैतिक वर्ग हैशकोड
{
सार्वजनिक स्थैतिक हैशकोडवैल्यू कॉम्बिनेशन (इंट हैश);
सार्वजनिक स्थैतिक हैशकोडवैल्यू कम्बाइन(टी ओबीजे);
सार्वजनिक स्थैतिक हैशकोडवैल्यू कम्बाइन(टी ओबीजे, आईईक्वालिटी कंपेयररतुलनाकर्ता);

    public struct HashCodeValue : IEquatable<HashCodeValue>
    {
        public HashCodeValue Combine(int hash);
        public HashCodeValue Combine<T>(T obj);
        public HashCodeValue Combine<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCodeValue hashCode);

        public static bool operator ==(HashCodeValue left, HashCodeValue right);
        public static bool operator !=(HashCodeValue left, HashCodeValue right);

        public bool Equals(HashCodeValue other);
        public override bool Equals(object obj);
        public override int GetHashCode();
    }
}

}
```

संपादित करें: हालांकि, शायद नेस्टेड प्रकार के लिए HashCodeValue से बेहतर नाम की आवश्यकता है यदि हम इस पथ से नीचे जाते हैं तो HashCodeValue.Value थोड़ा अनावश्यक है, ऐसा नहीं है कि Value का उपयोग बहुत अधिक किया जाएगा अक्सर। हो सकता है कि हमें Value संपत्ति की भी आवश्यकता न हो - यदि आप int डालना नहीं चाहते हैं तो आप Value माध्यम से GetHashCode() कर सकते हैं।

@justinvp पहली बार में दो अलग-अलग प्रकार होने में क्या समस्या है? उदाहरण के लिए, यह प्रणाली LinkedList<T> और LinkedListNode<T> लिए ठीक काम करती प्रतीत होती है।

हालाँकि, पहली बार में दो अलग-अलग प्रकार होने में क्या समस्या है?

दो शीर्ष-स्तरीय प्रकारों के साथ दो चिंताएँ हैं:

1. एपीआई के लिए "प्रवेश बिंदु" किस प्रकार का है? यदि नाम Hash और HashCode , तो आप किससे शुरू करते हैं? उन नामों से यह स्पष्ट नहीं है। LinkedList<T> और LinkedListNode<T> यह बहुत स्पष्ट है कि कौन सा मुख्य प्रवेश बिंदु है, LinkedList<T> , और कौन सा सहायक है।
2. System नाम स्थान को प्रदूषित कर रहा है। यह उतना अधिक चिंता का विषय नहीं है (1), लेकिन कुछ ध्यान में रखना चाहिए क्योंकि हम System नेमस्पेस में नई कार्यक्षमता को उजागर करने पर विचार करते हैं।

नेस्टिंग इन चिंताओं को कम करने में मदद करता है।

@justinvp

एपीआई के लिए "प्रवेश बिंदु" किस प्रकार का है? यदि नाम हैश और हैशकोड हैं, तो आप किसके साथ शुरू करते हैं? उन नामों से यह स्पष्ट नहीं है। LinkedList . के साथऔर LinkedListNodeयह बहुत स्पष्ट है कि मुख्य प्रवेश बिंदु कौन सा है, LinkedList, और जो एक सहायक है।

ठीक है, काफी उचित बिंदु। क्या होगा यदि हम प्रकार Hash और HashValue , न कि घोंसले के प्रकार? क्या यह दो प्रकार के बीच एक अधीनस्थ संबंध को पर्याप्त रूप से निरूपित करेगा?

यदि हम ऐसा करते हैं, तो फ़ैक्टरी विधि और भी संक्षिप्त हो जाती है: Hash.Combine(field1).Combine(field2) । साथ ही, अपने आप में संरचना प्रकार का उपयोग करना अभी भी व्यावहारिक है। उदाहरण के लिए, कोई हैश की एक सूची इकट्ठा करने के लिए है, और पाठक एक को यह संवाद करने के लिए चाहते हो सकता है List<HashValue> एक के बजाय प्रयोग किया जाता है List<int> । यदि हम नेस्टेड प्रकार बनाते हैं तो यह भी काम नहीं कर सकता है: List<HashCode.HashCodeValue> (यहां तक ​​​​कि List<Hash.Value> पहली नज़र में थोड़े भ्रमित करने वाला है)।

सिस्टम नेमस्पेस को प्रदूषित करना। यह उतना चिंता का विषय नहीं है जितना (1), लेकिन कुछ ध्यान में रखना चाहिए क्योंकि हम सिस्टम नेमस्पेस में नई कार्यक्षमता को उजागर करने पर विचार करते हैं।

मैं सहमत हूं, लेकिन मुझे यह भी लगता है कि यह महत्वपूर्ण है कि हम परंपरा का पालन करें और उपयोग में आसानी का त्याग न करें। उदाहरण के लिए, केवल बीसीएल एपीआई मैं सोच सकता हूं कि हमारे पास नेस्टेड प्रकार हैं (अपरिवर्तनीय संग्रह गिनती नहीं हैं, वे ढांचे का सख्ती से हिस्सा नहीं हैं) List<T>.Enumerator , जहां हम सक्रिय रूप से नेस्टेड को छिपाना चाहते हैं टाइप करें क्योंकि यह कंपाइलर उपयोग के लिए है। हम इस मामले में ऐसा नहीं करना चाहते हैं।

हो सकता है कि हमें वैल्यू प्रॉपर्टी की भी आवश्यकता न हो - यदि आप इंट में डालना नहीं चाहते हैं तो आप GetHashCode() के माध्यम से वैल्यू प्राप्त कर सकते हैं।

मैंने इसके बारे में पहले सोचा था। लेकिन फिर उपयोगकर्ता को कैसे पता चलेगा कि प्रकार ओवरराइड करता है GetHashCode , या कि इसका एक निहित ऑपरेटर है?

प्रस्तावित एपीआई

public static class Hash
{
    public static HashValue Combine(int hash);
    public static HashValue Combine<T>(T obj);
    public static HashValue Combine<T>(T obj, IEqualityComparer<T> comparer);
}

public struct HashValue : IEquatable<HashValue>
{
    public HashValue Combine(int hash);
    public HashValue Combine<T>(T obj);
    public HashValue Combine<T>(T obj, IEqualityComparer<T> comparer);

    public int Value { get; }

    public static implicit operator int(HashValue hashValue);

    public static bool operator ==(HashValue left, HashValue right);
    public static bool operator !=(HashValue left, HashValue right);

    public override bool Equals(object obj);
    public bool Equals(HashValue other);
    public override int GetHashCode();
}

क्या होगा यदि हमने हैश और हैशवैल्यू प्रकारों का नाम दिया है, न कि घोंसले के प्रकार?

Hash मेरे लिए एक नाम से बहुत सामान्य लगता है। मुझे लगता है कि हमें प्रवेश बिंदु एपीआई के नाम पर HashCode है क्योंकि इसका इच्छित उद्देश्य GetHashCode() को लागू करने में मदद करना है, न कि GetHash() ।

कोई हैश की एक सूची एकत्र करना चाहता है, और पाठक को इसे एक सूची में संवाद करना चाहता हैList . के बजाय प्रयोग किया जाता है. यदि हम नेस्टेड प्रकार बनाते हैं तो यह भी काम नहीं कर सकता है: सूची(यहां तक ​​कि सूचीपहली नज़र में थोड़ा भ्रमित करने वाला है)।

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

केवल बीसीएल एपीआई मैं सोच सकता हूं कि हमारे पास नेस्टेड प्रकार हैं

TimeZoneInfo.AdjustmentRule और TimeZoneInfo.TransitionTime बीसीएल में उदाहरण हैं जिन्हें जानबूझकर नेस्टेड प्रकारों के रूप में जोड़ा गया था।

@justinvp

मुझे लगता है कि हमें एंट्री पॉइंट एपीआई के नाम पर हैशकोड की आवश्यकता है क्योंकि इसका उद्देश्य गेटहाशकोड () को लागू करने में मदद करना है, न कि गेटहाश ()।

मैं देखता हूँ।

मैंने चीजों के बारे में थोड़ा और सोचा है। ऐसा लगता है कि नेस्टेड संरचना होना उचित है; जैसा कि आपने उल्लेख किया है, अधिकांश लोग वास्तविक प्रकार को कभी नहीं देख पाएंगे। बस एक बात: मुझे लगता है कि इस प्रकार को Seed के बजाय HashCodeValue कहा जाना चाहिए। इसके नाम का संदर्भ पहले से ही युक्त वर्ग द्वारा निहित है।

प्रस्तावित एपीआई

namespace System
{
    public static class HashCode
    {
        public static Seed Combine(int hash);
        public static Seed Combine<T>(T obj);
        public static Seed Combine<T>(T obj, IEqualityComparer<T> comparer);

        public struct Seed : IEquatable<Seed>
        {
            public Seed Combine(int hash);
            public Seed Combine<T>(T obj);
            public Seed Combine<T>(T obj, IEqualityComparer<T> comparer);

            public int Value { get; }

            public static implicit operator int(Seed seed);

            public static bool operator ==(Seed left, Seed right);
            public static bool operator !=(Seed left, Seed right);

            public bool Equals(Seed other);
            public override bool Equals(object obj);
            public override int GetHashCode();
        }
    }
}

@jamesqo इसके बजाय public readonly int Value होने के साथ कोई आपत्ति या कार्यान्वयन समस्या? Seed साथ समस्या यह है कि यह तकनीकी रूप से पहले संयोजन के बाद का बीज नहीं है।

@justinvp से भी सहमत हैं, Hash को हैश से निपटने के लिए आरक्षित किया जाना चाहिए। इसके बजाय HashCode से निपटने को आसान बनाने के लिए इसे पेश किया गया था।

@redknightlois स्पष्ट होने के लिए, हम संरचना के नाम के बारे में बात कर रहे थे, न कि संपत्ति के नाम के बारे में।

        public struct Seed : IEquatable<Seed>
        {
            public Seed Combine(int hash);
            public Seed Combine<T>(T obj);
            public Seed Combine<T>(T obj, IEqualityComparer<T> comparer);

            public int Value { get; }

            public static implicit operator int(Seed seed);

            public static bool operator ==(Seed left, Seed right);
            public static bool operator !=(Seed left, Seed right);

            public bool Equals(Seed other);
            public override bool Equals(object obj);
            public override int GetHashCode();
        }

उपयोग:
c# int hashCode = HashCode.Combine(field1).Combine(name, StringComparison.OrdinalIgnoreCase).Value; int hashCode = (int)HashCode.Combine(field1).Combine(field2);

बीज के साथ समस्या यह है कि यह तकनीकी रूप से पहले संयोजन के बाद का बीज नहीं है।

यह अगले गठबंधन के लिए एक बीज है, जो एक नया बीज पैदा करता है।

इसके बजाय सार्वजनिक रूप से पढ़ने योग्य int Value के साथ कोई आपत्ति या कार्यान्वयन समस्या?

क्यों? int Value { get; } अधिक मुहावरेदार है और इसे आसानी से रेखांकित किया जा सकता है।

यह अगले गठबंधन के लिए एक बीज है, जो एक नया बीज पैदा करता है।

क्या वह अंकुर नहीं होगा? ;)

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

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

मेरे अनुभव में जब जटिल कोड गुणों से घिरा होता है तो फ़ील्ड से भी बदतर कोड उत्पन्न होता है (उनमें से, गैर इनलाइन)।

यदि आपको एक एकल गैर-डीबग बिल्ड मिलता है जहां एक स्वत: कार्यान्वित संपत्ति हमेशा रेखांकित नहीं होती है, तो यह एक जेआईटी मुद्दा है और निश्चित रूप से तय किया जाना चाहिए।

इसके अलावा एक संरचना पर एक इंट का एक पठनीय क्षेत्र सीधे एक रजिस्टर में अनुवाद करता है

ऐसे अनुकूलन हैं जिनकी अनुमति दी जा सकती है क्योंकि इसका कारण यह हो सकता है कि यह केवल पढ़ने योग्य है।

इस संरचना का समर्थन क्षेत्र केवल पढ़ने के लिए होगा; एपीआई एक एक्सेसर होगा।

मुझे नहीं लगता कि किसी संपत्ति का उपयोग करने से यहां किसी भी तरह से प्रदर्शन प्रभावित होगा।

@jamesqo मैं इसे ध्यान में ढूंढूंगा । प्रदर्शन संवेदनशील कोड के लिए मैं अब गुणों का उपयोग नहीं करता (इस बिंदु पर मांसपेशी स्मृति)।

आप "बीज" के बजाय नेस्टेड संरचना "राज्य" को कॉल करने पर विचार कर सकते हैं?

@ellismg ज़रूर, सुझाव के लिए धन्यवाद। मैं आंतरिक संरचना के लिए एक अच्छे नाम के साथ आने के लिए संघर्ष कर रहा था।

@karelz मुझे लगता है कि यह एपीआई आखिरकार अच्छी है; इस बार, मैंने यह सुनिश्चित करने के लिए जाँच की कि सब कुछ संकलित है। जब तक किसी को कोई आपत्ति नहीं होगी, मैं इसके क्रियान्वयन पर काम करना शुरू कर दूंगा।

@jamesqo @JonHanna हम क्यों की क्या ज़रूरत है Combine<T>(T obj) के बजाय Combine(object o) ?

हमें कंबाइन की आवश्यकता क्यों है(टी ओबीजे) कंबाइन (ऑब्जेक्ट ओ) के बजाय?

उत्तरार्द्ध आवंटित करेगा यदि उदाहरण एक संरचना था।

दुह, स्पष्टीकरण के लिए धन्यवाद।

हमें नेस्टेड प्रकार पसंद नहीं है क्योंकि यह डिज़ाइन को जटिल बनाता है। मूल समस्या यह थी कि हम स्टैटिक्स और नॉन-स्टैटिक्स को एक ही नाम नहीं दे सकते। हमारे पास दो विकल्प हैं: स्टैटिक्स से छुटकारा पाएं या नाम बदलें। हमें लगता है कि Create नाम बदलने से सबसे अधिक समझ में आता है क्योंकि यह डिफ़ॉल्ट कंस्ट्रक्टर का उपयोग करने की तुलना में काफी पठनीय कोड बनाता है।

जब तक कोई मजबूत विरोध न हो, यही वह डिजाइन है जिस पर हमने समझौता किया है:

```सी#
नेमस्पेस सिस्टम
{
सार्वजनिक संरचना हैशकोड: IEquatable
{
सार्वजनिक स्थैतिक हैशकोड बनाएं (int हैशकोड);
सार्वजनिक स्थैतिक हैशकोड बनाएँ(टी ओबीजे);
सार्वजनिक स्थैतिक हैशकोड बनाएँ(टी ओबीजे, आईईक्वालिटी कंपेयररतुलनाकर्ता);

    public HashCode Combine(int hashCode);
    public HashCode Combine<T>(T obj);
    public HashCode Combine<T>(T obj, IEqualityComparer<T> comparer);

    public int Value { get; }

    public static implicit operator int(HashCode hashCode);

    public static bool operator ==(HashCode left, HashCode right);
    public static bool operator !=(HashCode left, HashCode right);

    public bool Equals(HashCode other);
    public override bool Equals(object obj);
    public override int GetHashCode();
}

}
```

आइए अतिरिक्त प्रतिक्रिया के लिए कुछ दिनों तक प्रतीक्षा करें ताकि यह पता लगाया जा सके कि स्वीकृत प्रस्ताव पर कोई मजबूत प्रतिक्रिया है या नहीं। तब हम इसे 'पकड़ने के लिए' बना सकते हैं।

यह डिजाइन को जटिल क्यों करता है? मैं समझ सकता था कि यह कितना बुरा होगा यदि हमें वास्तव में कोड में हैशकोड.स्टेट का उपयोग करना पड़े (उदाहरण के लिए एक चर के प्रकार को परिभाषित करने के लिए) लेकिन क्या हम उम्मीद करते हैं कि अक्सर ऐसा ही होता है? ज्यादातर बार मैं या तो मूल्य को पूरी तरह वापस कर दूंगा या एक int में परिवर्तित कर दूंगा और उसे संग्रहीत कर दूंगा।

मुझे लगता है कि बनाएं और कम्बाइन का संयोजन बदतर है।

कृपया देखें https://github.com/dotnet/corefx/issues/8034#issuecomment -262661653

@terrajobst

हमें लगता है कि क्रिएट का नाम बदलने से सबसे ज्यादा फायदा होता है क्योंकि यह डिफॉल्ट कंस्ट्रक्टर का उपयोग करने की तुलना में काफी पठनीय कोड बनाता है।

जब तक कोई मजबूत विरोध न हो, यही वह डिजाइन है जिस पर हमने समझौता किया है:

मैं तुम्हें सुनते हैं, लेकिन मैं एक आखिरी मिनट में सोचा जब मैं कार्यान्वयन पर काम कर रहा था था ... हम बस एक स्थिर जोड़ सकते हैं Zero / Empty करने के लिए संपत्ति HashCode , और फिर क्या लोग वहां से Combine कॉल करते हैं? यह हमें अलग Combine / Create विधियों से मुक्त करेगा।

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
        public static HashCode Empty { get; }

        public HashCode Combine(int hashCode);
        public HashCode Combine<T>(T obj);
        public HashCode Combine<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public bool Equals(HashCode other);
        public override bool Equals(object obj);
        public override int GetHashCode();
    }
}

int GetHashCode()
{
    return HashCode.Empty
        .Combine(_1)
        .Combine(_2);
}

किसी और को लगता है कि यह एक अच्छा विचार है? (मैं इस बीच एक पीआर जमा करूंगा, और अगर लोग ऐसा सोचते हैं तो मैं इसे पीआर में बदल दूंगा।)

@jamesqo , मुझे खाली/शून्य विचार पसंद है।

मुझे लगता है कि (के बीच कोई मजबूत वरीयता के साथ ठीक होगा Empty बनाम Create ... @weshaggard @bartonjs @stephentoub @terrajobst क्या तुम लोग सोचते हैं कारखाना)?

मुझे व्यक्तिगत रूप से लगता है कि बनाएं() बेहतर है; लेकिन मुझे HashCode.Empty new HashCode() से बेहतर पसंद है।

चूंकि यह एक ऐसे संस्करण की अनुमति देता है जिसमें कोई ऑपरेटर-नया नहीं है, और यह बाद में निर्णय लेने से रोकता नहीं है कि हम वास्तव में बूटस्ट्रैपर के रूप में बनाना चाहते हैं ... :: श्रग ::।

यह मेरे पुशबैक की पूरी सीमा है (उर्फ बहुत ज्यादा नहीं)।

FWIW मैं Empty / Zero बजाय Create लिए वोट करूंगा। मैं Empty / Zero से सब कुछ लटका देने के बजाय वास्तविक मूल्य के साथ शुरू करना चाहता हूं। यह सिर्फ अजीब लगता है / लगता है।

यह शून्य के साथ सीडिंग करने वाले लोगों को भी हतोत्साहित करता है, जो एक गरीब बीज होता है।

मैं खाली के बजाय बनाएँ पसंद करता हूँ। मैं इसके बारे में कैसे सोचता हूं इसके साथ यह जीवंत है: मैं हैश कोड बनाना चाहता हूं और अतिरिक्त मूल्यों में मिश्रण करना चाहता हूं। मैं नेस्टेड दृष्टिकोण के साथ भी ठीक हो जाऊंगा।

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

@ जोनहन्ना सिर्फ स्पष्ट करने के लिए: आपका मतलब Create लिए वोट के रूप में था, है ना?

और चौथे पर सोचा कि कैसे बनाएं के बजाय साथ के बारे में।

हैशकोड। (ए) के साथ। गठबंधन (बी)। गठबंधन (सी)

नवीनतम चर्चा के आधार पर उदाहरण उपयोग ( Create संभवतः w/एक वैकल्पिक नाम को बदल दिया गया है):

```सी#
सार्वजनिक ओवरराइड int GetHashCode () =>
हैशकोड। क्रिएट (_फील्ड 1)। कॉम्बाइन (_फील्ड 2)। कॉम्बिनेशन (_फील्ड 3);

We went down the path of this chaining approach, but didn't reconsider earlier proposals when the static & instance `Combine` methods didn't pan out...

Are we sure we don't want something like the existing `Path.Combine` pattern, that was proposed previously, with a handful of generic `Combine` overloads? e.g.:

```c#
public override int GetHashCode() =>
    HashCode.Combine(_field1, _field2, _field3);

@justinvp असंगत कोड की ओर ले जाएगा + अधिक झटकेदार मुझे लगता है कि अधिक सामान्य संयोजनों के बी/सी। अगर यह वांछनीय हो जाता है तो हम इसे किसी अन्य मुद्दे पर फिर से देख सकते हैं।

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

मैं इसका उल्लेख नहीं करने जा रहा था क्योंकि यह थोड़ा असामान्य है और मुझे अभी भी यकीन नहीं है कि मैं इसके बारे में कैसा महसूस करता हूं, लेकिन यहां एक और विचार है, यह सुनिश्चित करने के लिए कि सभी विकल्पों पर विचार किया गया है ...

क्या होगा अगर हमने ASP.NET कोर के परिवर्तनशील HashCodeCombiner "बिल्डर" की तर्ज पर कुछ किया, समान Add विधियों के साथ, लेकिन संग्रह प्रारंभकर्ता सिंटैक्स के लिए समर्थन भी शामिल किया?

उपयोग:

```सी#
सार्वजनिक ओवरराइड int GetHashCode () =>
नया हैशकोड { _field1, _field2, _field3};

With a surface area something like:

```c#
namespace System
{
    public struct HashCode : IEquatable<HashCode>, IEnumerable
    {
        public void Add(int hashCode);
        public void Add<T>(T obj);
        public void Add<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public bool Equals(HashCode other);
        public override bool Equals(object obj);
        public override int GetHashCode();

        IEnumerator IEnumerable.GetEnumerator();
    }
}

इसे कम से कम IEnumerable के साथ कम से कम एक Add विधि को लागू करना होगा ताकि संग्रह प्रारंभकर्ता सिंटैक्स को सक्षम किया जा सके। IEnumerable को इंटेलिजेंस से छिपाने के लिए स्पष्ट रूप से लागू किया जा सकता है और GetEnumerator या तो NotSupportedException फेंक सकता है या हैश कोड मान को गणना में एक संयुक्त आइटम के रूप में वापस कर सकता है, अगर कोई ऐसा करता है इसका उपयोग करें (जो दुर्लभ होगा)।

@justinvp , आपके पास एक दिलचस्प विचार है। हालाँकि, मैं सम्मानपूर्वक असहमत हूँ; मुझे लगता है कि HashCode को म्यूटेबल स्ट्रक्चर्स के साथ गोचर्स से बचने के लिए अपरिवर्तनीय रखा जाना चाहिए। इसके लिए IEnumerable को लागू करना भी कृत्रिम/परतदार लगता है; अगर किसी के पास फ़ाइल में using System.Linq निर्देश है, तो Cast<> और OfType<> विस्तार विधियों के रूप में दिखाई देंगे यदि वे HashCode बगल में एक बिंदु डालते हैं। मुझे लगता है कि हमें मौजूदा प्रस्ताव के करीब रहना चाहिए।

@jamesqo , मैं सहमत हूं - इसलिए इसका उल्लेख करने में भी मेरी झिझक है। केवल एक चीज जो मुझे पसंद है वह यह है कि उपयोग चेनिंग की तुलना में क्लीनर हो सकता है, लेकिन यह स्वयं एक और कमी है क्योंकि यह स्पष्ट नहीं है कि नमूना उपयोग को देखे बिना संग्रह प्रारंभकर्ताओं का भी उपयोग किया जा सकता है।

@MadsTorgersen , @jaredpar , संग्रह प्रारंभकर्ता को IEnumerable\ के कार्यान्वयन की आवश्यकता क्यों है@justinvp की तीसरी टिप्पणी ऊपर।

@jamesqo , मैं मानता हूं कि इसे अपरिवर्तनीय रखना बेहतर है (और IEnumerable नहीं \

@ मेलिनो मुझे लगता है कि साधारण मामले को थोड़ा आसान बना देगा, लेकिन यह उससे भी अधिक जटिल (और क्या करना सही है इसके बारे में कम स्पष्ट) से परे कुछ भी बना देगा।

जिसमें शामिल है:

1. आपके पास ओवरलोड की तुलना में अधिक आइटम
2. शर्तेँ
3. छोरों
4. तुलनाकर्ता का उपयोग करना

इस विषय पर पहले पोस्ट किए गए ASP.NET के कोड पर विचार करें (वर्तमान प्रस्ताव में अद्यतन):

```सी#
वर हैशकोड = हैशकोड
.क्रिएट (IsMainPage)
.Combine(ViewName, StringComparer.Ordinal)
.Combine(ControllerName, StringComparer.Ordinal)
.Combine(AreaName, StringComparer.Ordinal);

अगर (ViewLocationExpanderValues!= null)
{
foreach (ViewLocationExpanderValues ​​​​में var आइटम)
{
हैशकोड = हैशकोड
.Combine(item.Key, StringComparer.Ordinal)
.Combine(item.Value, StringComparer.Ordinal);
}
}

वापसी हैशकोड;

How would this look with the original `Hash.CombineHashCodes`? I think it would be:

```c#
var hashCode = Hash.CombineHashCodes(
    IsMainPage,
    StringComparer.Ordinal.GetHashCode(ViewName),
    StringComparer.Ordinal.GetHashCode(ControllerName),
    StringComparer.Ordinal.GetHashCode(AreaName));

if (ViewLocationExpanderValues != null)
{
    foreach (var item in ViewLocationExpanderValues)
    {
        hashCode = Hash.CombineHashCodes(
            hashCode
            StringComparer.Ordinal.GetHashCode(item.Key),
            StringComparer.Ordinal.GetHashCode(item.Value));
    }
}

return hashCode;

यहां तक ​​​​कि अगर आप कस्टम तुलनाकर्ताओं के लिए GetHashCode() को कॉल करने की उपेक्षा करते हैं, तो मुझे लगता है कि पहले पैरामीटर के रूप में hashCode का पिछला मान सीधा नहीं है।

@KrzysztofCwalina @ericlippert के अनुसार की में सी # प्रोग्रामिंग भाषा टिप्पणी <sup>1,</sup> क्योंकि संग्रह initializers हैं (आश्चर्य) संग्रह निर्माण के लिए वाक्य रचना चीनी, गणित के लिए नहीं है (जो नामित विधि के अन्य आम उपयोग था मतलब है Add )।

<sup>1</sup> Google पुस्तकें कैसे काम करती हैं, इसके कारण हो सकता है कि वह लिंक सभी के लिए काम न करे।

@KrzysztofCwalina , और ध्यान दें, इसके लिए गैर-जेनेरिक IEnumerable , न कि IEnumerable<T> ।

@svick, ऊपर अपने पहले उदाहरण में मामूली निट: करने के लिए पहली कॉल .Combine होगा .Create वर्तमान प्रस्ताव के साथ। जब तक हम नेस्टेड दृष्टिकोण का उपयोग नहीं करते।

@svick

यह इससे परे कुछ भी अधिक जटिल बना देगा (और क्या करना सही है इसके बारे में कम स्पष्ट)

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

@justinvp धन्यवाद, अपडेट किया गया। (मैं पहली पोस्ट में पहले प्रस्ताव के साथ गया था, और यह नहीं पता था कि यह पुराना है, किसी को शायद इसे अपडेट करना चाहिए।)

@ मेलिनो समस्या वास्तव में यह है कि दूसरा सूक्ष्म बग उत्पन्न कर सकता है। यह हमारी परियोजनाओं में से एक से वास्तविक कोड है।

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public int GetHashCode(PageFromScratchBuffer obj)
        {
            int v = Hashing.Combine(obj.NumberOfPages, obj.ScratchFileNumber);
            int w = Hashing.Combine(obj.Size.GetHashCode(), obj.PositionInScratchBuffer.GetHashCode());
            return Hashing.Combine(v, w);            
        }

हम इसके साथ रहते हैं, लेकिन हम हर दिन बहुत निम्न स्तर की चीजों से निपट रहे हैं; तो औसत डेवलपर नहीं जो निश्चित रूप से है। हालाँकि, यहाँ v को w के साथ संयोजित करने के लिए समान नहीं है, v के साथ w ... को v और w के बीच में समान रूप से जोड़ा जाता है। हैश संयोजन कम्यूटिव नहीं हैं, इसलिए एक के बाद एक चेनिंग करने से वास्तव में एपीआई स्तर पर त्रुटियों के पूरे सेट से छुटकारा मिल सकता है।

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

किया हुआ।
BTW: इस प्रस्ताव पर नज़र रखना बहुत कठिन है, विशेष रूप से वोट ... इतने सारे बदलाव (जो मुझे लगता है कि अच्छा है ;-))

@karelz अगर हम Create एपीआई जोड़ते हैं तो मुझे लगता है कि हम अभी भी Empty जोड़ सकते हैं। यह एक या दूसरे होने की जरूरत नहीं है, जैसा कि @bartonjs ने कहा था। प्रस्तावित

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
        public HashCode();

        public static HashCode Empty { get; }

        public static HashCode Create(int hashCode);
        public static HashCode Create<T>(T value);
        public static HashCode Create<T>(T value, IEqualityComparer<T> comparer);

        public HashCode Combine(int hashCode);
        public HashCode Combine<T>(T value);
        public HashCode Combine<T>(T value, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public bool Equals(HashCode other);
        public override bool Equals(object obj);
        public override int GetHashCode();
        public override string ToString();
    }
}

@JonHanna

यह शून्य के साथ सीडिंग करने वाले लोगों को भी हतोत्साहित करता है, जो एक गरीब बीज होता है।

हम जो हैशिंग एल्गोरिदम चुन रहे हैं वह वही होगा जो आज HashHelpers में उपयोग किया गया है, जिसका प्रभाव hash(0, x) == x । HashCode.Empty.Combine(x) ठीक उसी तरह के परिणाम देगा जैसे HashCode.Create(x) , इसलिए वस्तुनिष्ठ रूप से कोई अंतर नहीं है।

@jamesqo आप अपने पिछले प्रस्ताव में अतिरिक्त Zero शामिल करना भूल गए। अगर वह एक चूक थी, तो क्या आप इसे अपडेट कर सकते हैं? फिर हम लोगों से आपके नवीनतम प्रस्ताव के लिए वोट करने के लिए कह सकते हैं। अन्य विकल्पों की तरह दिखता है (शीर्ष पोस्ट देखें जिसे मैंने अपडेट किया है) इतना निम्नलिखित नहीं मिलता है ...

@karelz स्पॉटिंग के लिए धन्यवाद, तय।

@KrzysztofCwalina यह जांचने के लिए कि संग्रह में जोड़ने के अर्थ में आपका मतलब "जोड़ें" है, किसी अन्य अर्थ में नहीं। मुझे नहीं पता कि मुझे यह प्रतिबंध पसंद है या नहीं, लेकिन हमने उस समय यही तय किया था।

public static HashCode Create(int hash);
public HashCode Combine(int hash);

पैरामीटर का नाम hashCode के बजाय hash के बाद से पारित कर दिया-में मूल्य की संभावना बुला से प्राप्त एक हैश कोड होने जा रहा है GetHashCode() ?

Empty / Zero

अगर हम इसे बनाए रखते हैं, तो विचार करने के लिए एक और नाम Default ।

@justinvp

क्या पैरामीटर को हैश के बजाय हैशकोड नाम दिया जाना चाहिए क्योंकि पास-इन मान GetHashCode() को कॉल करने से प्राप्त होने वाला हैश कोड होने जा रहा है?

मैं int पैरामीटर hash और HashCode पैरामीटर hashCode नाम देना चाहता था। हालांकि दूसरे विचार पर, मुझे विश्वास है कि hashCode बेहतर होगा क्योंकि, जैसा कि आपने उल्लेख किया है, hash थोड़े अस्पष्ट है। मैं एपीआई अपडेट करूंगा।

यदि हम इसे बनाए रखते हैं, तो विचार करने के लिए एक और नाम डिफ़ॉल्ट है।

जब मैं Default सुनता हूं तो मुझे लगता है कि "कुछ करने का नियमित तरीका जब आप नहीं जानते कि कौन सा विकल्प चुनना है," नहीं "एक संरचना का डिफ़ॉल्ट मान।" उदाहरण के लिए Encoding.Default जैसा कुछ बिल्कुल अलग अर्थ है।

हम जो हैशिंग एल्गोरिदम चुन रहे हैं वह वही होगा जो आज हैश हेल्पर्स में उपयोग किया जाता है, जिसका प्रभाव हैश (0, x) == x है। HashCode.Empty.Combine(x) ठीक उसी तरह के परिणाम देगा जैसे HashCode.Create(x), इसलिए इसमें कोई अंतर नहीं है।

किसी ऐसे व्यक्ति के रूप में जो इसके आंतरिक भाग के बारे में अधिक नहीं जानता है, मुझे वास्तव में HashCode.Create(x).Combine(...) की सादगी पसंद है। Create बहुत स्पष्ट है, क्योंकि इसका उपयोग कई अन्य स्थानों पर किया जाता है।

यदि Empty / Zero / Default कोई एल्गोरिथम उपयोग प्रदान नहीं करता है, तो यह आईएमओ नहीं होना चाहिए।

पीएस: बहुत दिलचस्प धागा !! बहुत बढ़िया! मैं

@cwe1ss

यदि खाली/शून्य/डिफ़ॉल्ट कोई एल्गोरिदमिक उपयोग प्रदान नहीं करता है, तो यह आईएमओ नहीं होना चाहिए।

Empty फ़ील्ड होने से एल्गोरिथम उपयोग मिलता है। यह एक "शुरुआती मूल्य" का प्रतिनिधित्व करता है जिससे आप हैश को जोड़ सकते हैं। उदाहरण के लिए, यदि आप Create का सख्ती से उपयोग करके हैश की एक सरणी को जोड़ना चाहते हैं, तो यह बहुत दर्दनाक है:

int CombineRange(int[] hashes)
{
    if (hashes.Length == 0)
    {
        return 0;
    }

    var result = HashCode.Create(hashes[0]);

    for (int i = 1; i < hashes.Length; i++)
    {
        result = result.Combine(hashes[i]);
    }

    return result;
}

यदि आपके पास Empty , तो यह बहुत अधिक स्वाभाविक हो जाता है:

int CombineRange(int[] hashes)
{
    var result = HashCode.Empty;

    for (int i = 0; i < hashes.Length; i++)
    {
        result = result.Combine(hashes[i]);
    }

    return result;
}

// or

int CombineRange(int[] hashes)
{
    return hashes.Aggregate(HashCode.Empty, (hc, next) => hc.Combine(next));
}

@terrajobst यह प्रकार मेरे लिए ImmutableArray<T> के समान है। एक खाली सरणी अपने आप में बहुत उपयोगी नहीं है, लेकिन अन्य कार्यों के लिए "शुरुआती बिंदु" के रूप में बहुत उपयोगी है, और इसलिए हमारे पास इसके लिए Empty संपत्ति है। मुझे लगता है कि HashCode लिए भी एक होना समझ में आता है; हम Create रख रहे हैं।

@jamesqo मैंने देखा है कि आपने अपने प्रस्ताव https://github.com/dotnet/corefx/issues/8034#issuecomment -262661653 में चुपचाप/दुर्घटना से तर्क नाम obj से value में बदल दिया है। मैंने इसे वापस obj स्विच कर दिया, जो IMO आपको जो मिलता है उसे बेहतर तरीके से कैप्चर करता है। नाम value इस संदर्भ में "int" हैश मान के साथ अधिक जुड़ा हुआ है।
यदि आवश्यक हो तो मैं तर्क नाम पर आगे की चर्चा के लिए तैयार हूं, लेकिन आइए इसे उद्देश्य पर बदलें और पिछले स्वीकृत प्रस्ताव के अंतर का ट्रैक रखें।

मैंने शीर्ष पर प्रस्ताव को अद्यतन किया है। मैंने प्रस्ताव के अंतिम स्वीकृत संस्करण के खिलाफ अंतर का भी आह्वान किया।

हम जो हैशिंग एल्गोरिदम चुन रहे हैं वह वही होगा जो आज हैश हेल्पर्स में उपयोग किया जाता है

इसे हर जगह इस्तेमाल किए जाने वाले एल्गोरिदम के रूप में चुनना एक अच्छा एल्गोरिदम क्यों है? हैशकोड के संयुक्त होने के बारे में यह क्या धारणा बनाने जा रहा है? यदि इसका उपयोग हर जगह किया जाता है, तो क्या यह DDoS हमलों के लिए नए रास्ते खोलने वाला है? (ध्यान दें कि हम अतीत में स्ट्रिंग हैशिंग के लिए इससे जल चुके हैं।)

क्या होगा अगर हमने ASP.NET Core के परिवर्तनशील HashCodeCombiner "बिल्डर" की तर्ज पर कुछ किया

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

इसे हर जगह इस्तेमाल किए जाने वाले एल्गोरिदम के रूप में चुनना एक अच्छा एल्गोरिदम क्यों है?

इसे हर जगह इस्तेमाल नहीं किया जाना चाहिए। https://github.com/dotnet/corefx/issues/8034#issuecomment -260790829 पर मेरी टिप्पणी देखें; यह मुख्य रूप से उन लोगों पर लक्षित है जो हैशिंग के बारे में ज्यादा नहीं जानते हैं। जो लोग जानते हैं कि वे क्या कर रहे हैं, वे इसका मूल्यांकन करके देख सकते हैं कि यह उनकी आवश्यकताओं के अनुरूप है या नहीं।

हैशकोड के संयुक्त होने के बारे में यह क्या धारणा बनाने जा रहा है? यदि इसका उपयोग हर जगह किया जाता है, तो क्या यह DDoS हमलों के लिए नए रास्ते खोलने वाला है?

हमारे पास वर्तमान हैश के साथ एक समस्या यह है कि hash(0, x) == x । तो अगर हैश को नल या शून्य की एक श्रृंखला खिलाई जाती है तो यह 0 रहेगा। कोड देखें। यह कहना नहीं है कि नल की गिनती नहीं है, लेकिन प्रारंभिक नल में से कोई भी नहीं करता है। मैं यहाँ की तरह कुछ अधिक मजबूत (लेकिन थोड़ा अधिक महंगा) का उपयोग करने पर विचार कर रहा हूं, जो शून्य से शून्य की मैपिंग से बचने के लिए एक जादू स्थिरांक जोड़ता है।

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

मुझे नहीं लगता कि एक बड़े संरचना आकार के साथ एक सार्वभौमिक संयोजक होना चाहिए जो हर उपयोग के मामले में फिट होने का प्रयास करे। इसके बजाय मैं अलग हैश कोड प्रकारों की कल्पना कर रहा था जो सभी int-size ( FnvHashCode , आदि) हैं और सभी की अपनी Combine विधियां हैं। इसके अलावा, इन "बिल्डर" प्रकारों को वैसे भी उसी तरीके से रखा जा रहा है, जो पास नहीं हुआ है।

मुझे नहीं लगता कि एक बड़े संरचना आकार के साथ एक सार्वभौमिक संयोजक होना चाहिए जो हर उपयोग के मामले में फिट होने का प्रयास करे।

क्या ASP.NET Core अपने स्वयं के हैशकोड कॉम्बिनर को बदलने में सक्षम होने जा रहा है - जिसमें वर्तमान में 64-बिट राज्य है - इसके साथ?

मैं अलग-अलग हैश कोड प्रकारों की कल्पना कर रहा था जो सभी अंतर-आकार (FnvHashCode, आदि) हैं।

क्या इससे संयुक्त विस्फोट नहीं होता? यह एपीआई प्रस्ताव का हिस्सा होना चाहिए ताकि यह स्पष्ट किया जा सके कि यह एपीआई डिजाइन किस ओर ले जाता है।

@jkotas मैंने चर्चा की शुरुआत में इसी तरह की आपत्तियां https://github.com/dotnet/corefx/issues/13757

मैं मानता हूं कि हैशकोड कॉम्बिनर होना अच्छा विचार है जो 99% मामलों में उपयोग करने के लिए कोई ब्रेनर नहीं है। हालांकि, इसे केवल 32-बिट की तुलना में अधिक आंतरिक स्थिति की अनुमति देने की आवश्यकता है।

BTW: ASP.NET ने मूल रूप से हैशकोड संयोजन के लिए धाराप्रवाह पैटर्न का उपयोग किया, लेकिन इसे करना बंद कर दिया क्योंकि इससे बग आसानी से छूट गए: https://github.com/aspnet/Razor/pull/537

@jkotas हैश-बाढ़ सुरक्षा के संबंध में।
अस्वीकरण: विशेषज्ञ नहीं (आपको एक से परामर्श लेना चाहिए और एमएस के पास इस मुद्दे पर कुछ से अधिक हैं) ।

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

संपादित करें: जब मैं लिख रहा था तब आपने पोस्ट किया था। इसके आलोक में, आपके लिए 64 बिट राज्य को क्या लाभ होता है?

@jkotas मैंने आपके द्वारा लिंक किए गए मुद्दे को देखा। इसे कहते हैं:

एस्पनेट/सामान्य#40 . पर प्रतिक्रिया

https://github.com/aspnet/Common/issues/40 का विवरण:

बग स्पॉट करें:

public class TagBuilder
{
    private Dictionary<string, string> _attributes;
    private string _tagName;
    private string _innerContent;

    public override int GetHashCode()
    {
        var hash = HashCodeCombiner.Start()
            .Add(_tagName, StringComparer.Ordinal)
            .Add(_innerContent, StringComparer.Ordinal);

        foreach (var kvp in _attributes)
        {
            hash.Add(kvp.Key, StringComparer.Ordinal).Add(kvp.Value, StringComparer.Ordinal);
        }

        return hash.Build();
    }
}

कामे ओन। यह तर्क यह कहने जैसा है कि string परिवर्तनशील होना चाहिए क्योंकि लोगों को यह एहसास नहीं होता है कि Substring एक नई स्ट्रिंग देता है। गोचर्स के मामले में म्यूटेबल स्ट्रक्चर कहीं ज्यादा खराब हैं; मुझे लगता है कि हमें संरचना को अपरिवर्तनीय रखना चाहिए।

हैश-बाढ़ सुरक्षा के संबंध में।

इसके दो पहलू हैं: निर्माण द्वारा सही डिजाइन (मजबूत डेटास्ट्रक्चर, आदि); और मौजूदा डिजाइन में मुद्दों का शमन। दोनों ही महत्वपूर्ण हैं।

@karelz पैरामीटर नामकरण के संबंध में

मैंने देखा है कि आपने अपने प्रस्ताव dotnet/corefx#8034 (टिप्पणी) में चुपचाप/दुर्घटना से arg नाम obj को value में बदल दिया है। मैंने इसे वापस ओबीजे पर स्विच कर दिया जो आईएमओ आपको जो मिलता है उसे बेहतर तरीके से कैप्चर करता है। इस संदर्भ में नाम मान "int" हैश मान से अधिक जुड़ा हुआ है।
यदि आवश्यक हो तो मैं तर्क नाम पर आगे की चर्चा के लिए तैयार हूं, लेकिन आइए इसे उद्देश्य पर बदलें और पिछले स्वीकृत प्रस्ताव के अंतर का ट्रैक रखें।

मैं भविष्य के प्रस्ताव में, थोक में मूल्यों को संयोजित करने के लिए एपीआई जोड़ने पर विचार कर रहा हूं। उदाहरण के लिए: CombineRange(ReadOnlySpan<T>) । अगर हमने इसे obj नाम दिया है, तो हमें वहां पैरामीटर को नाम देना होगा objs , जो बहुत अजीब लगता है। इसलिए हमें इसके बजाय इसे item नाम देना चाहिए; भविष्य में, हम स्पैन पैरामीटर को नाम दे सकते हैं items । प्रस्ताव को अपडेट किया।

@jkotas सहमत हैं, लेकिन यहाँ बिंदु यह है कि हम संयोजक स्तर पर कुछ भी कम नहीं कर रहे हैं ...

केवल एक चीज जो हम कर सकते हैं वह है एक यादृच्छिक बीज, जो सभी राज्यों और उद्देश्यों के लिए मुझे याद है कि मैंने string पर कोड देखा है और यह प्रति बिल्ड तय है। (इसके बारे में गलत हो सकता है, क्योंकि वह बहुत समय पहले था)। यादृच्छिक बीजों का उचित कार्यान्वयन ही एकमात्र शमन है जो यहां लागू हो सकता है।

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

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

मान लें कि आपके पास M1 और M2 अलग-अलग यादृच्छिक बीजों के साथ rs1 और rs2 ....
M1 h1 = hash('a', rs1) और h2=hash('b', rs1)
M2 h1' = hash('a', rs2) और h2'=hash('b', rs2)
यहां मुख्य बिंदु यह है कि h1 और h1' एक संभावना के साथ भिन्न होगा 1/ (int.MaxInt-1) (यदि hash पर्याप्त है) जो सभी उद्देश्यों के लिए है अच्छा है क्योंकि यह मिलने वाला है।
इसलिए जो भी c(x,y) आप उपयोग करने का निर्णय लेते हैं (यदि पर्याप्त हो तो) पहले से ही स्रोत में अंतर्निहित शमन को ध्यान में रखते हैं।

संपादित करें: मुझे कोड मिला, आप मार्विन 32 का उपयोग कर रहे हैं जो अब प्रत्येक डोमेन पर बदलता है। तो स्ट्रिंग्स के लिए शमन प्रति रन यादृच्छिक बीज का उपयोग कर रहा है। जैसा कि मैंने कहा, काफी अच्छा शमन है।

@jkotas

क्या ASP.NET Core अपने स्वयं के हैशकोड कॉम्बिनर को बदलने में सक्षम होने जा रहा है - जिसमें वर्तमान में 64-बिट राज्य है - इसके साथ?

बिल्कुल; यह समान हैशिंग एल्गोरिथम का उपयोग करता है। मैंने टक्करों की संख्या को मापने के लिए अभी यह परीक्षण ऐप बनाया है और इसे 10 बार चलाया है। 64 बिट्स का उपयोग करने से कोई महत्वपूर्ण अंतर नहीं है।

मैं अलग-अलग हैश कोड प्रकारों की कल्पना कर रहा था जो सभी अंतर-आकार (FnvHashCode, आदि) हैं।

क्या इससे संयुक्त विस्फोट नहीं होता? यह एपीआई प्रस्ताव का हिस्सा होना चाहिए ताकि यह स्पष्ट किया जा सके कि यह एपीआई डिजाइन किस ओर ले जाता है।

@jkotas , यह नहीं होगा। इस वर्ग का डिज़ाइन भविष्य के हैशिंग एपीआई के लिए डिज़ाइन को पत्थर में सेट नहीं करेगा। उन्हें अधिक उन्नत परिदृश्य माना जाना चाहिए, एक अलग प्रस्ताव में जाना चाहिए जैसे कि डॉटनेट/कोरएफएक्स # 13757, और एक अलग डिजाइन चर्चा होगी। मेरा मानना ​​​​है कि एक सामान्य हैशिंग एल्गोरिथ्म के लिए एक सरल एपीआई होना कहीं अधिक महत्वपूर्ण है, नए लोगों के लिए जो ओवरराइडिंग के साथ संघर्ष कर रहे हैं GetHashCode ।

मैं मानता हूं कि हैशकोड कॉम्बिनर होना अच्छा विचार है जो 99% मामलों में उपयोग करने के लिए कोई ब्रेनर नहीं है। हालांकि, इसे केवल 32-बिट की तुलना में अधिक आंतरिक स्थिति की अनुमति देने की आवश्यकता है।

हमें 32 बिट से अधिक आंतरिक स्थिति की आवश्यकता कब होगी? संपादित करें: यदि यह लोगों को कस्टम हैशिंग तर्क में प्लग करने की अनुमति देना है, तो मुझे लगता है (फिर से) इसे एक उन्नत परिदृश्य माना जाना चाहिए और डॉटनेट/कोरएफएक्स # 13757 में चर्चा की जानी चाहिए।

आप Marvin32 का उपयोग कर रहे हैं जो अब प्रत्येक डोमेन पर बदलता है

ठीक है, स्ट्रिंग हैशकोड रैंडमाइजेशन शमन डिफ़ॉल्ट रूप से .NET कोर में सक्षम है। यह संगतता के कारण पूर्ण .NET Framework में स्टैंडअलोन ऐप्स के लिए डिफ़ॉल्ट रूप से सक्षम नहीं है; यह केवल विचित्रताओं के माध्यम से सक्षम है (उदाहरण के लिए उच्च जोखिम वाले वातावरण में)।

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

यादृच्छिक स्ट्रिंग हैशकोड की गणना करने के लिए उपयोग किए जाने वाले मार्विन 32 एल्गोरिदम में 64-बिट आंतरिक स्थिति है। इसे एमएस विषय विशेषज्ञों द्वारा चुना गया था। मुझे पूरा यकीन है कि उनके पास 64-बिट आंतरिक स्थिति का उपयोग करने का एक अच्छा कारण था, और उन्होंने इसका उपयोग केवल चीजों को धीमा करने के लिए नहीं किया है।

एक सामान्य उद्देश्य हैश कॉम्बिनर को इस शमन को विकसित करते रहना चाहिए: इसे एक यादृच्छिक बीज और एक मजबूत पर्याप्त हैशकोड संयोजन एल्गोरिथम का उपयोग करना चाहिए। आदर्श रूप से, यह उसी मार्विन 32 को यादृच्छिक स्ट्रिंग हैशिंग के रूप में उपयोग करेगा।

यादृच्छिक स्ट्रिंग हैशकोड की गणना करने के लिए उपयोग किए जाने वाले मार्विन 32 एल्गोरिदम में 64-बिट आंतरिक स्थिति है। इसे एमएस विषय विशेषज्ञों द्वारा चुना गया था। मुझे पूरा यकीन है कि उनके पास 64-बिट आंतरिक स्थिति का उपयोग करने का एक अच्छा कारण था, और उन्होंने इसका उपयोग केवल चीजों को धीमा करने के लिए नहीं किया है।

@jkotas , आपके द्वारा लिंक किया गया हैश कोड संयोजक Marvin32 का उपयोग नहीं करता है। यह गैर-यादृच्छिक string.GetHashCode द्वारा उपयोग किए जाने वाले समान अनुभवहीन DJBx33x एल्गोरिथम का उपयोग करता है।

एक सामान्य उद्देश्य हैश कॉम्बिनर को इस शमन को विकसित करते रहना चाहिए: इसे एक यादृच्छिक बीज और एक मजबूत पर्याप्त हैशकोड संयोजन एल्गोरिथम का उपयोग करना चाहिए। आदर्श रूप से, यह उसी मार्विन 32 को यादृच्छिक स्ट्रिंग हैशिंग के रूप में उपयोग करेगा।

इस प्रकार का उपयोग उन जगहों पर करने का इरादा नहीं है जो हैश DoS हमलों से ग्रस्त हैं। यह उन लोगों के लिए लक्षित है जो जोड़ने/xor के बारे में बेहतर नहीं जानते हैं, और https://github.com/dotnet/coreclr/pull/4654 जैसी चीजों को रोकने में मदद करेंगे

एक सामान्य उद्देश्य हैश कॉम्बिनर को इस शमन को विकसित करते रहना चाहिए: इसे एक यादृच्छिक बीज और एक मजबूत पर्याप्त हैशकोड संयोजन एल्गोरिथम का उपयोग करना चाहिए। आदर्श रूप से, यह उसी मार्विन 32 को यादृच्छिक स्ट्रिंग हैशिंग के रूप में उपयोग करेगा।

फिर हमें सी # टीम के साथ बात करनी चाहिए ताकि वे ValueTuple हैशिंग एल्गोरिथम को कम कर सकें। क्योंकि उस कोड का उपयोग उच्च जोखिम वाले वातावरण में भी किया जाने वाला है। और निश्चित रूप से Tuple https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Tuple.cs#L60 या System.Numerics.HashHelpers (पूरे विश्व में प्रयुक्त) जगह)।

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

यह उन लोगों के लिए लक्षित है जो जोड़ना/xor . के बारे में बेहतर नहीं जानते हैं

यही कारण है कि इसका मजबूत होना जरूरी है। .NET का प्रमुख मूल्य यह है कि यह उन लोगों की समस्याओं का समाधान करता है जो बेहतर नहीं जानते हैं।

और जब हम इस पर हों, तो IntPtr बारे में न भूलें https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/IntPtr.cs#L119
वह एक विशेष रूप से बुरा है, xor शायद हमारे वहां सबसे खराब है क्योंकि bad के साथ टकराव होगा dab ।

एक कम ValueTuple हैशिंग एल्गोरिदम लागू करें

अच्छी बात। मुझे यकीन नहीं है कि क्या ValueTuple भेज दिया गया है या क्या यह अभी भी ऐसा करने का समय है। https://github.com/dotnet/corefx/issues/14046 खोला गया

आइए IntPtr . के बारे में न भूलें

ये पिछली गलतियाँ हैं ... इन्हें ठीक करने की सीमा बहुत अधिक है।

@jkotas

ये पिछली गलतियाँ हैं ... इन्हें ठीक करने की सीमा बहुत अधिक है।

मैंने सोचा था कि नेट कोर के बिंदुओं में से एक यह है कि "छोटे" परिवर्तनों के लिए बार बहुत कम होना चाहिए। अगर कोई IntPtr.GetHashCode (जो उन्हें वास्तव में नहीं करना चाहिए) के कार्यान्वयन पर निर्भर करता है, तो वे .Net Core के अपने संस्करण को अपग्रेड नहीं करने का विकल्प चुन सकते हैं।

इस तरह के "छोटे" परिवर्तनों के लिए बार बहुत कम होना चाहिए

हाँ, यह है - पूर्ण .NET Framework की तुलना में। लेकिन आपको अभी भी सिस्टम के माध्यम से बदलाव लाने के लिए काम करना है और आप पाएंगे कि यह दर्द के लायक नहीं है। हाल का उदाहरण Tuple<T> हैशिंग एल्गोरिथम में परिवर्तन है जो F# के टूटने के कारण वापस आ गया है: https://github.com/dotnet/coreclr/pull/6767#issuecomment -256896016

@jkotas

अगर हम HashCode 64-बिट बनाते, तो क्या आपको लगता है कि एक अपरिवर्तनीय डिज़ाइन 32-बिट वातावरण में पूर्ण को मार देगा? मैं अन्य पाठकों से सहमत हूं, एक बिल्डर पैटर्न बहुत खराब लगता है।

पूर्ण को मार डालो - नहीं। सिंटैक्स चीनी के लिए भुगतान किया गया प्रदर्शन जुर्माना - हाँ।

सिंटैक्स चीनी के लिए भुगतान किया गया प्रदर्शन जुर्माना - हाँ।

क्या यह ऐसा कुछ है जिसे भविष्य में जेआईटी द्वारा अनुकूलित किया जा सकता है?

परफेक्ट को मारता है - नहीं।
सिंटैक्स चीनी के लिए भुगतान किया गया प्रदर्शन जुर्माना - हाँ।

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

आपको पहले से उद्धृत करना:

यही कारण है कि इसका मजबूत होना जरूरी है। .NET का प्रमुख मूल्य यह है कि यह उन लोगों की समस्याओं का समाधान करता है जो बेहतर नहीं जानते हैं।

मैं तर्क दूंगा कि अधिकांश लोगों के लिए एक परिवर्तनीय मूल्य प्रकार एक मजबूत एपीआई नहीं है जो बेहतर नहीं जानते हैं।

मैं तर्क दूंगा कि अधिकांश लोगों के लिए एक परिवर्तनीय मूल्य प्रकार एक मजबूत एपीआई नहीं है जो बेहतर नहीं जानते हैं।

सहमत। सोचा, मुझे लगता है कि यह दुर्भाग्यपूर्ण है कि यह परिवर्तनीय संरचना निर्माता प्रकारों का मामला है। मैं का उपयोग उन सभी समय की वजह से वे अच्छा और तंग कर रहे हैं। [MustNotCopy] एनोटेशन किसी को भी?

मस्टनॉटकॉपी एक संरचना प्रेमी का सपना सच होने जैसा है। @jaredpar?

MustNotCopy केवल स्टैक की तरह है लेकिन उपयोग करने में और भी कठिन है

मेरा सुझाव है कि कोई वर्ग न बनाएं लेकिन हैश को गठबंधन करने के लिए विस्तार विधियां बनाएं

static class HashHelpers
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash(this int hash1, int hash2);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, T value);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, T value, IEqualityComparer<T> comparer);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, IEnumerable<T> values);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, IEnumerable<T> values, IEqualityComparer<T> comparer);
}

बस इतना ही! यह तेज़ और उपयोग में आसान है।

@AlexRadch मुझे यह पसंद नहीं है कि सभी पूर्णांकों के लिए विधि सूची को प्रदूषित करता है, न कि केवल हैश के रूप में।

इसके अलावा, आपके पास ऐसे तरीके हैं जो हैश कोड की गणना की एक श्रृंखला जारी रखते हैं, लेकिन आप इसे कैसे शुरू करते हैं? क्या आपको कुछ गैर-स्पष्ट करना है जैसे शून्य से शुरू करना? यानी 0.CombineHash(this.FirstName).CombineHash(this.LastName) ।

अद्यतन: dotnet/corefx#14046 में टिप्पणी के अनुसार, यह निर्णय लिया गया कि मौजूदा हैश फॉर्मूला ValueTuple लिए रखा जाएगा:

@jamesqo मदद के लिए धन्यवाद।
@jkotas और @VSadov के साथ अंतिम चर्चा से, हम यादृच्छिककरण/सीडिंग के साथ आगे बढ़ना ठीक हैं, लेकिन अधिक महंगे हैश फ़ंक्शन को अपनाने से पीछे
रैंडमाइजेशन करने से भविष्य में जरूरत पड़ने पर हैश फंक्शन को बदलने का द्वार बना रहता है।

@jkotas , क्या हम वर्तमान ROL 5-आधारित हैश को HashCode लिए रख सकते हैं, और इसे वापस 4 बाइट्स तक सिकोड़ सकते हैं? यह स्ट्रक्चर कॉपी करने की सभी समस्याओं को खत्म कर देगा। हमारे पास HashCode.Empty एक यादृच्छिक हैश मान का प्रतिनिधित्व कर सकता है।

@svick
हाँ यह सभी पूर्णांकों के लिए विधियों को प्रदूषित करता है, लेकिन इसे अलग नाम स्थान में रखा जा सकता है और यदि आप हैश के साथ काम नहीं करते हैं तो आप इसे शामिल नहीं करेंगे और नहीं देखेंगे।

0.CombineHash(this.FirstName).CombineHash(this.LastName) को this.FirstName.GetHash().CombineHash(this.LastName) रूप में लिखा जाना चाहिए

बीज से शुरू करने को लागू करने के लिए इसकी अगली स्थिर विधि हो सकती है

static class HashHelpers
{
    public static int ClassSeed<T>();
}

class SomeClass
{
    int GetHash()
    {
        return HashHelpers.ClassSeed<SomeClass>().CombineHash(value1).CombineHash(value2);
    }
}

तो प्रत्येक वर्ग में यादृच्छिक हैश के लिए अलग-अलग बीज होंगे।

@jkotas , क्या हम वर्तमान ROL 5-आधारित हैश को हैशकोड के लिए रख सकते हैं, और इसे वापस 4 बाइट्स तक सिकोड़ सकते हैं?

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

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

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

देखें कि एक अच्छा हैश फ़ंक्शन क्या बनाता है (जो कुछ स्पष्ट रूप से xor : http://softwareengineering.stackexchange.com/questions/49550/who-hashing-algorithm-is-best-for-uniqueness-and -गति और https://research.neustar.biz/2012/02/02/choosing-a-good-hash-function-part-3/

@jamesqo बीटीडब्लू, मुझे अभी एहसास हुआ कि संयोजक इस मामले के लिए काम नहीं करेगा: "मैं वास्तव में हैश (रनटाइम हैश नहीं) का संयोजन कर रहा हूं क्योंकि बीज हर बार बदल जाएगा।" ... बीज के साथ सार्वजनिक निर्माता?

@jkotas

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

क्या इससे कोई फर्क पड़ता है जब अंत में यह एक int में संघनित हो जाएगा?

@jamesqo वास्तव में नहीं, राज्य का आकार केवल कार्य पर निर्भर करता है, मजबूती पर नहीं। वास्तव में आप वास्तव में अपने हैश फ़ंक्शन को बदतर बना सकते हैं, यह गठबंधन उस तरह से काम करने के लिए डिज़ाइन नहीं किया गया है, और सबसे अच्छा आप संसाधनों को बर्बाद कर रहे हैं क्योंकि आप जबरदस्ती से यादृच्छिकता प्राप्त नहीं कर सकते हैं।

कोरोलरी: यह आप सुनिश्चित कर रहे हैं कि फ़ंक्शन सांख्यिकीय रूप से उत्कृष्ट है या आप इसे बदतर बनाने के लिए लगभग गारंटीकृत हैं।

यह इस बात पर निर्भर करता है कि वस्तुओं के बीच संबंध है या नहीं। यदि कोई सहसंबंध नहीं है, तो 32-बिट स्थिति और सरल रोटल (या यहां तक ​​​​कि xor) ठीक काम करता है। यदि सहसंबंध है, तो यह निर्भर करता है।

विचार करें कि क्या किसी ने अलग-अलग वर्णों से स्ट्रिंग हैशकोड बनाने के लिए इसका इस्तेमाल किया है। ऐसा नहीं है कि यह संभावना है कि कोई वास्तव में स्ट्रिंग के लिए ऐसा करेगा, लेकिन यह समस्या का प्रदर्शन करता है:

for (int i = 0; i < str.Length; i++)
   hashCodeBuilder.Add(str[i]);

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

एपीआई समर्थन हैश रैंडमाइजेशन के लिए अगली विधि जोड़ना बहुत अच्छा होगा।

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
       // add this
       public static HashCode CreateRandomized(Type type);
       // or add this
       public static HashCode CreateRandomized<T>();
    }
}

@jkotas मैंने इसका परीक्षण नहीं किया है, इसलिए मुझे विश्वास है कि आपने किया था। लेकिन यह निश्चित रूप से उस फ़ंक्शन के बारे में कुछ कह रहा है जिसका हम उपयोग करना चाहते हैं। यदि आप विश्वसनीयता के लिए गति का व्यापार करना चाहते हैं तो यह पर्याप्त रूप से

अगर हम चाहते हैं कि हमारा लक्ष्य यह है कि कोई भी इसके साथ बेवकूफी न करे, 64 बिट राज्य का उपयोग करना कुछ भी ठीक नहीं कर रहा है, हम सिर्फ समस्या को छुपा रहे हैं। एक इनपुट बनाना अभी भी संभव होगा जो उस सहसंबंध का फायदा उठाएगा। जो हमें फिर से उसी तर्क की ओर इशारा करता है जो मैंने 18 दिन पहले किया था। देखें: https://github.com/dotnet/corefx/issues/8034#issuecomment -261301533

मैं एक बार डिजाइन का समर्थन करता हूं कि यह एक गैर-क्रिप्टो हैशिंग फ़ंक्शन नहीं है, बल्कि असंबद्ध हैश-कोड को संयोजित करने का एक तेज़ तरीका है

असंबद्ध हैश-कोड को संयोजित करने का सबसे तेज़ तरीका xor...

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

public static HashCode CreateRandomized(Type type); या public static HashCode CreateRandomized<T>(); विधियों या दोनों के साथ हैश कोड यादृच्छिकरण जोड़ें।

@jkotas मुझे लगता है कि मुझे इसके लिए एक बेहतर पैटर्न मिल गया होगा। क्या होगा अगर हम सी # 7 रेफरी रिटर्न का इस्तेमाल करते हैं? हर बार HashCode वापस करने के बजाय, हम एक ref HashCode लौटाएंगे जो एक रजिस्टर में फिट बैठता है।

public struct HashCode
{
    private readonly long _value;

    public ref HashCode Combine(int hashCode)
    {
        CombineCore(ref _value, hashCode); // note: modifies the struct in-place
        return ref this;
    }
}

उपयोग पहले जैसा ही रहता है:

return HashCode.Combine(1)
    .Combine(2).Combine(3);

केवल नकारात्मक पक्ष यह है कि हम फिर से एक परिवर्तनशील संरचना में वापस आ गए हैं। लेकिन मुझे नहीं लगता कि एक ही समय में नकल और अपरिवर्तनीयता दोनों का कोई तरीका नहीं है।

( ref this अभी तक काम नहीं करता है, लेकिन मैं इसे यहां सक्षम करने के लिए रोसलिन में एक पीआर देखता हूं

@AlexRadch मुझे नहीं लगता कि हैश को प्रकार के साथ जोड़ना बुद्धिमानी है, क्योंकि प्रकार का हैश कोड प्राप्त करना महंगा है।

@jamesqo public static HashCode CreateRandomized<T>(); टाइप हैश कोड नहीं मिलता है। यह इस प्रकार के लिए यादृच्छिक हैशकोड बनाता है।

@jamesqo " ref this अभी तक काम नहीं करता है"। यहां तक ​​​​कि एक बार रोसलिन मुद्दा तय हो जाने पर, ref this कुछ समय के लिए कोरएफएक्स रेपो के लिए उपलब्ध नहीं होगा (मुझे यकीन नहीं है कि कितनी देर तक, @stephentoub शायद अपेक्षाएं निर्धारित कर सकता है)।

डिजाइन चर्चा यहां अभिसरण नहीं कर रही है। इसके अलावा 200 टिप्पणियों का पालन करना बहुत कठिन है।
हम अगले सप्ताह @jkotas को हथियाने की योजना बना रहे हैं और अगले मंगलवार को एपीआई समीक्षा में प्रस्ताव को

एक तरफ: मैं इस मुद्दे को बंद करने और "धन्य प्रस्ताव" के साथ एक नया बनाने का सुझाव देता हूं जब हमारे पास लंबी चर्चा का पालन करने के बोझ को कम करने के लिए अगले सप्ताह होता है। मुझे बताएं कि क्या आपको लगता है कि यह एक बुरा विचार है।

@jcouv मैं ठीक हूं इसके साथ अभी तक काम नहीं कर रहा है, इसलिए जब तक हम इस डिजाइन का पालन कर सकते हैं जब इसे जारी किया जाता है। (मुझे यह भी लगता है कि Unsafe का उपयोग करके अस्थायी रूप से इसके आसपास काम करना संभव हो सकता है।)

@karelz ठीक है: मुस्कान: जब मेरे पास समय होगा तो मैं इस प्रस्ताव को बाद में बंद कर दूंगा, और एक नया खोलूंगा। मैं सहमत हूँ; मेरा ब्राउज़र 200+ टिप्पणियों को अच्छी तरह से संभाल नहीं सकता है।

@karelz मैंने एक रोड़ा मारा; यह पता चला है कि विचाराधीन पीआर मूल्य प्रकारों के विपरीत संदर्भ प्रकारों के लिए ref this रिटर्न को सक्षम करने का प्रयास कर रहा था। ref this को स्ट्रक्चर्स से सुरक्षित रूप से वापस नहीं किया जा सकता है; यहाँ देखें क्यों। इसलिए रेफ-रिटर्निंग समझौता काम नहीं करेगा।

वैसे भी, मैं इस मुद्दे को बंद कर दूंगा। मैंने यहां एक और मुद्दा खोला है: https://github.com/dotnet/corefx/issues/14354

एक मूल्य प्रकार विस्तार विधि पोस्ट https://github.com/dotnet/roslyn/pull/15650 से रेफरी "यह" वापस करने में सक्षम होना चाहिए, हालांकि मुझे लगता है कि सी # वीनेक्स्ट ...

@बेनादम्स

एक मूल्य प्रकार विस्तार विधि पोस्ट डॉटनेट/रोसलिन # 15650 से रेफरी "यह" वापस करने में सक्षम होना चाहिए, हालांकि मुझे लगता है कि सी # वीनेक्स्ट ...

सही। ref this एक्सटेंशन विधि से this वापस करना संभव है। हालांकि सामान्य संरचना उदाहरण विधि से this वापस करना संभव नहीं है। ऐसा क्यों है, इसके बारे में बहुत सारे जीवन भर के विवरण हैं :(

@redknightlois

अगर हम सख्त होना चाहते हैं तो एकमात्र हैश uint होना चाहिए, इसे एक निरीक्षण के रूप में देखा जा सकता है कि ढांचा उस प्रकाश के तहत int लौटाता है।

सीएलएस-अनुपालन? अहस्ताक्षरित पूर्णांक सीएलएस-अनुपालन नहीं हैं।