[डॉटनेटबुक] स्पैन: नई .NET डेटा टाइप

इस लेख के साथ, मैं लेखों की एक श्रृंखला प्रकाशित करना जारी रखता हूं, जिसके परिणामस्वरूप .NET सीएलआर के काम पर एक पुस्तक होगी, और सामान्य रूप से .NET। पुस्तक के लगभग 200 पृष्ठ पहले से ही तैयार हैं, इसलिए लिंक के लिए लेख के अंत में आपका स्वागत है)।

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

मंच के डेवलपर्स ने मानव रहित संसाधनों का उपयोग करके विकास के रोजमर्रा के जीवन को उज्ज्वल बनाने में हमारी मदद करने की कोशिश की है: ये आयातित तरीकों के लिए स्वचालित रैपर हैं। और मार्शलिंग, जो ज्यादातर मामलों में स्वचालित रूप से काम करता है। यह stackallloc निर्देश भी है, जिसे थ्रेड स्टैक पर अध्याय में चर्चा की गई है। हालाँकि, मेरे लिए, यदि C # का उपयोग करने वाले शुरुआती डेवलपर C ++ की दुनिया से आए (जैसा कि मैंने किया था), अब वे उच्च-स्तरीय भाषाओं से आते हैं (उदाहरण के लिए, मैं एक डेवलपर को जानता हूं जो JavaScript से आया था)। इसका क्या मतलब है? इसका मतलब यह है कि लोगों को अप्रबंधित संसाधनों और निर्माणों पर संदेह है जो कि C / C ++ की तरह आत्मा के समान हैं और यहां तक ​​कि असेंबलर के लिए भी।

टिप्पणी

हैबे पर प्रकाशित अध्याय अद्यतन नहीं है और, शायद, पहले से ही थोड़ा पुराना है। और इसलिए, कृपया हाल के पाठ के लिए मूल पर जाएं:

• सीएलआर बुक: गिटहब, सामग्री की तालिका
• सीएलआर बुक: गिटहब, चैप्टर
• 0.5.2 पुस्तकें, PDF: GitHub रिलीज़ जारी करें

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

क्लास इंटरॉप। रीडिर
/src/mscorlib/shared/Interop/Unix/System.Native/Interop.ReadDir.cs

 unsafe { // s_readBufferSize is zero when the native implementation does not support reading into a buffer. byte* buffer = stackalloc byte[s_readBufferSize]; InternalDirectoryEntry temp; int ret = ReadDirR(dir.DangerousGetHandle(), buffer, s_readBufferSize, out temp); // We copy data into DirectoryEntry to ensure there are no dangling references. outputEntry = ret == 0 ? new DirectoryEntry() { InodeName = GetDirectoryEntryName(temp), InodeType = temp.InodeType } : default(DirectoryEntry); return ret; } 

यह अलोकप्रियता का कारण स्पष्ट हो जाता है। कोड को पढ़े बिना देखें और अपने लिए एक प्रश्न का उत्तर दें: क्या आपको इस पर भरोसा है? मैं मान सकता हूं कि उत्तर नहीं है। फिर दूसरे को उत्तर दें: क्यों? उत्तर स्पष्ट होगा: Dangerous शब्द को देखने के अलावा, जो किसी तरह संकेत देता है कि कुछ गलत हो सकता है, हमारे दृष्टिकोण को प्रभावित करने वाला दूसरा कारक लाइन byte* buffer = stackalloc byte[s_readBufferSize]; , और अधिक विशेष रूप से, byte* । यह रिकॉर्ड किसी के लिए भी एक ट्रिगर है ताकि मेरे सिर में चिन्तन हो जाए: "क्या, क्या नहीं किया जा सकता है? तो फिर आइए मनोविश्लेषण पर थोड़ा और ध्यान दें: ऐसा विचार क्यों उत्पन्न हो सकता है? एक ओर, हम भाषा निर्माण का उपयोग करते हैं और यहां प्रस्तावित वाक्यविन्यास, उदाहरण के लिए, C ++ / CLI से बहुत दूर है, जो आपको कुछ भी करने की अनुमति देता है (शुद्ध असेंबलर पर आवेषण सहित), और दूसरी तरफ, यह असामान्य दिखता है।

तो सवाल क्या है? डेवलपर्स को मानव रहित कोड की वापस कैसे लौटाएं? उन्हें यह समझने की जरूरत है कि वे अज्ञानता से बाहर निकल कर गलती से गलती नहीं कर सकते। तो, Span<T> और Memory<T> क्यों Span<T> किए गए हैं?

स्पैन [टी], रीडऑनस्पैन [टी]

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

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

  var array = new [] {1,2,3,4,5,6}; var span = new Span<int>(array, 1, 3); var position = span.BinarySearch(3); Console.WriteLine(span[position]); // -> 3 

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

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

 void Main() { var array = new [] {'1','2','3','4','5','6'}; var span = new Span<char>(array, 1, 3); if(TryParseInt32(span, out var res)) { Console.WriteLine(res); } else { Console.WriteLine("Failed to parse"); } } public bool TryParseInt32(Span<char> input, out int result) { result = 0; for (int i = 0; i < input.Length; i++) { if(input[i] < '0' || input[i] > '9') return false; result = result * 10 + ((int)input[i] - '0'); } return true; } ----- 234 

जैसा कि हम देख सकते हैं, Span<T> पढ़ने और लिखने दोनों के लिए स्मृति के एक निश्चित टुकड़े तक पहुंच का एक अमूर्तता का परिचय देता है। यह हमें क्या देता है? यदि हम याद करते हैं कि Span को किस आधार पर बनाया जा सकता है, तो हम मानव रहित संसाधनों और रेखाओं को याद करते हैं:

 // Managed array var array = new[] { '1', '2', '3', '4', '5', '6' }; var arrSpan = new Span<char>(array, 1, 3); if (TryParseInt32(arrSpan, out var res1)) { Console.WriteLine(res1); } // String var srcString = "123456"; var strSpan = srcString.AsSpan().Slice(1, 3); if (TryParseInt32(strSpan, out var res2)) { Console.WriteLine(res2); } // void * Span<char> buf = stackalloc char[6]; buf[0] = '1'; buf[1] = '2'; buf[2] = '3'; buf[3] = '4'; buf[4] = '5'; buf[5] = '6'; if (TryParseInt32(buf.Slice(1, 3), out var res3)) { Console.WriteLine(res3); } ----- 234 234 234 

यही है, यह पता चला है कि Span<T> मेमोरी के साथ काम करने में एकीकरण का एक साधन है: प्रबंधित और अप्रबंधित, जो कचरा संग्रह के दौरान इस तरह के डेटा के साथ काम करने में सुरक्षा की गारंटी देता है: यदि प्रबंधित सरणियों के साथ मेमोरी क्षेत्र चलते हैं, तो इसके लिए यह हमारे लिए सुरक्षित होगा।

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

 public readonly ref struct OurSpan<T> { private T[] _array; private string _str; private T * _buffer; // ... } 

या, यदि आप आर्किटेक्चर से शुरू करते हैं, तो तीन प्रकार के होते हैं जो एकल इंटरफ़ेस को विरासत में देते हैं। यह पता चला है कि टूल को इन डेटा प्रकारों के बीच एकीकृत इंटरफ़ेस बनाने के लिए, अधिकतम प्रदर्शन को बनाए रखते हुए, Span<T> अलावा कोई रास्ता नहीं है।

इसके अलावा, चर्चा जारी रखने के लिए, Span संदर्भ में एक ref struct क्या है? ये वास्तव में बहुत ही "संरचनाएं हैं, वे केवल स्टैक पर हैं," जो हम अक्सर साक्षात्कार में सुनते हैं। और इसका मतलब है कि यह डेटा प्रकार केवल स्टैक के माध्यम से जा सकता है और ढेर में जाने का अधिकार नहीं है। और इसलिए, Span , रेफरी संरचना होने के नाते, एक संदर्भ डेटा प्रकार है जो तरीकों को प्रदान करता है, लेकिन स्मृति में ऑब्जेक्ट नहीं। इससे, उसकी समझ के लिए, हमें आगे बढ़ना चाहिए।

यहाँ से हम स्पैन टाइप की परिभाषा और इसके साथ जुड़े ReadOnlySpan टाइप कर सकते हैं:

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

और वास्तव में: अगर हमारे पास इस कोड जैसा कुछ है:

 public void Method1(Span<byte> buffer) { buffer[0] = 0; Method2(buffer.Slice(1,2)); } Method2(Span<byte> buffer) { buffer[0] = 0; Method3(buffer.Slice(1,1)); } Method3(Span<byte> buffer) { buffer[0] = 0; } 

तब स्रोत बफर तक पहुंच की गति यथासंभव अधिक होगी: आप एक प्रबंधित ऑब्जेक्ट के साथ नहीं, बल्कि एक प्रबंधित सूचक के साथ काम कर रहे हैं। यानी .NET प्रबंधित प्रकार के साथ नहीं, बल्कि एक प्रबंधित शेल में लिपटे एक असुरक्षित प्रकार के साथ।

उदाहरणों द्वारा स्पैन [टी]

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

ValueStringBuilder

सबसे एल्गोरिदमिक रूप से दिलचस्प उदाहरणों में से एक ValueStringBuilder प्रकार है, जो mscorlib के ValueStringBuilder में कहीं दबे हुए हैं और किसी कारण से, कई अन्य दिलचस्प डेटा प्रकारों की तरह, internal संशोधक के साथ चिह्नित हैं, जिसका अर्थ है कि अगर यह mscorlib स्रोत कोड के अध्ययन के लिए नहीं था, तो हम इस तरह के एक अद्भुत अनुकूलन विधि के बारे में बात करेंगे। कभी पता नहीं चलेगा।

StringBuilder सिस्टम प्रकार का मुख्य माइनस क्या है? यह, निश्चित रूप से, इसका सार है: दोनों वह खुद और वह क्या पर आधारित है (और यह char[] वर्णों की एक सरणी है) संदर्भ प्रकार हैं। और इसका मतलब है कि कम से कम दो चीजें: हम अभी भी (थोड़ा सा) एक गुच्छा लोड करते हैं और दूसरा - हम प्रोसेसर कैश पर मिस की संभावना बढ़ाते हैं।

एक और सवाल जो मैंने स्ट्रिंगबुलस्ट के लिए किया था वह था छोटे तारों का बनना। यानी जब परिणाम पंक्ति "दांत दे" छोटी होगी: उदाहरण के लिए, 100 से कम अक्षर। जब हमारे पास बहुत कम प्रारूपण होते हैं, तो प्रदर्शन समस्याएँ उत्पन्न होती हैं:

  $"{x} is in range [{min};{max}]" 

StringBuilder के माध्यम से मैन्युअल पीढ़ी की तुलना में यह रिकॉर्ड कितना खराब है? इसका उत्तर हमेशा स्पष्ट होता है: यह सब गठन की जगह पर निर्भर करता है: इस पद्धति को कितनी बार कहा जाएगा। सब के बाद, पहली स्ट्रिंग ।ormat आंतरिक StringBuilder लिए मेमोरी आवंटित करता है, जो वर्णों का एक सरणी बनाएगा (SourceString.Length + args.Length * 8) और अगर सरणी के निर्माण के दौरान यह पता चला कि लंबाई का अनुमान नहीं लगाया गया था, तो एक और StringBuilder निरंतरता बनाने के लिए बनाया जाएगा। जिससे एक साधारण रूप से जुड़ी सूची बनती है। और परिणामस्वरूप, उत्पन्न लाइन को वापस करना आवश्यक होगा: और यह एक और प्रतिलिपि है। भटकना और भटकना। अब, यदि हम ढेर पर बनने वाले स्ट्रिंग के पहले सरणी को रखने से छुटकारा पा सकते हैं, तो यह अद्भुत होगा: हम निश्चित रूप से एक समस्या से छुटकारा पाएंगे।

mscorlib के mscorlib से प्रकार पर एक नज़र डालें:

कक्षा मान
/ src / mscorlib / साझा / प्रणाली / पाठ / ValueStringBuilder

  internal ref struct ValueStringBuilder { //           private char[] _arrayToReturnToPool; //     private Span<char> _chars; private int _pos; //    ,       public ValueStringBuilder(Span<char> initialBuffer) { _arrayToReturnToPool = null; _chars = initialBuffer; _pos = 0; } public int Length { get => _pos; set { int delta = value - _pos; if (delta > 0) { Append('\0', delta); } else { _pos = value; } } } //   -       public override string ToString() { var s = new string(_chars.Slice(0, _pos)); Clear(); return s; } //       //     :   public void Insert(int index, char value, int count) { if (_pos > _chars.Length - count) { Grow(count); } int remaining = _pos - index; _chars.Slice(index, remaining).CopyTo(_chars.Slice(index + count)); _chars.Slice(index, count).Fill(value); _pos += count; } [MethodImpl(MethodImplOptions.AggressiveInlining)] public void Append(char c) { int pos = _pos; if (pos < _chars.Length) { _chars[pos] = c; _pos = pos + 1; } else { GrowAndAppend(c); } } [MethodImpl(MethodImplOptions.NoInlining)] private void GrowAndAppend(char c) { Grow(1); Append(c); } //   ,     //         //            //           [MethodImpl(MethodImplOptions.NoInlining)] private void Grow(int requiredAdditionalCapacity) { Debug.Assert(requiredAdditionalCapacity > _chars.Length - _pos); char[] poolArray = ArrayPool<char>.Shared.Rent(Math.Max(_pos + requiredAdditionalCapacity, _chars.Length * 2)); _chars.CopyTo(poolArray); char[] toReturn = _arrayToReturnToPool; _chars = _arrayToReturnToPool = poolArray; if (toReturn != null) { ArrayPool<char>.Shared.Return(toReturn); } } [MethodImpl(MethodImplOptions.AggressiveInlining)] private void Clear() { char[] toReturn = _arrayToReturnToPool; this = default; // for safety, to avoid using pooled array if this instance is erroneously appended to again if (toReturn != null) { ArrayPool<char>.Shared.Return(toReturn); } } //  :       private void AppendSlow(string s); public bool TryCopyTo(Span<char> destination, out int charsWritten); public void Append(string s); public void Append(char c, int count); public unsafe void Append(char* value, int length); public Span<char> AppendSpan(int length); } 

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

क्लास स्ट्रिंगबर्ल / एसकेएस / एसएमएसस्क्लिब / एससीवी / सिस्टम / टेक्स्ट / स्ट्रिंगबुलस्टिक्स।

 public sealed class StringBuilder : ISerializable { // A StringBuilder is internally represented as a linked list of blocks each of which holds // a chunk of the string. It turns out string as a whole can also be represented as just a chunk, // so that is what we do. internal char[] m_ChunkChars; // The characters in this block internal StringBuilder m_ChunkPrevious; // Link to the block logically before this block internal int m_ChunkLength; // The index in m_ChunkChars that represent the end of the block internal int m_ChunkOffset; // The logical offset (sum of all characters in previous blocks) internal int m_MaxCapacity = 0; // ... internal const int DefaultCapacity = 16; 

StringBuilder एक ऐसा वर्ग है जिसके अंदर वर्णों की एक कड़ी होती है। यानी जब आप इसे बनाते हैं, तो वास्तव में, कम से कम दो ऑब्जेक्ट बनाए जाते हैं: स्ट्रिंगबर्बस्ट खुद और कम से कम 16 वर्णों के वर्णों की एक सरणी (इस तरह, कि स्ट्रिंग की अनुमानित लंबाई निर्दिष्ट करना इतना महत्वपूर्ण है: इसका निर्माण 16-वर्ण सरणियों की एक एकल कनेक्ट की गई सूची की पीढ़ी के माध्यम से जाएगा। )। ValueStringBuilder प्रकार के बारे में हमारी बातचीत के संदर्भ में इसका क्या मतलब है: क्षमता डिफ़ॉल्ट रूप से अनुपस्थित है, क्योंकि यह बाहर से मेमोरी लेता है, साथ ही यह एक महत्वपूर्ण प्रकार है और उपयोगकर्ता को स्टैक पर पात्रों के लिए एक बफर आवंटित करने के लिए मजबूर करता है। नतीजतन, पूरे प्रकार का उदाहरण अपनी सामग्री के साथ स्टैक पर धकेल दिया जाता है, और यहां अनुकूलन समस्या हल हो जाती है। ढेर पर स्मृति आवंटन नहीं? ढेर पर प्रदर्शन sagging के साथ कोई समस्या नहीं है। लेकिन तुम मुझे बताओ: क्यों नहीं ValueStringBuilder का उपयोग करें (या इसका स्व-लिखित संस्करण: क्या यह आंतरिक है और हमारे लिए सुलभ नहीं है) हमेशा? जवाब है: आपको उस समस्या को देखने की जरूरत है जिसे आप हल कर रहे हैं। क्या परिणामी स्ट्रिंग ज्ञात आकार की होगी? क्या इसकी लंबाई में एक निश्चित ज्ञात अधिकतम होगा? यदि उत्तर हां है और अगर स्ट्रिंग आकार कुछ उचित सीमाओं से आगे नहीं जाता है, तो आप स्ट्रिंगबर्स्टोन के एक सार्थक संस्करण का उपयोग कर सकते हैं। अन्यथा, यदि हम लंबी लाइनों की अपेक्षा करते हैं, तो हम नियमित संस्करण का उपयोग करने के लिए स्विच करते हैं।

ValueListBuilder

दूसरा डेटा प्रकार जिसे मैं विशेष रूप से नोट करना चाहता हूं वह है ValueListBuilder प्रकार। यह उन स्थितियों के लिए बनाया गया था जब थोड़े समय के लिए तत्वों का एक संग्रह बनाना आवश्यक होता है और इसे तुरंत प्रसंस्करण के लिए कुछ एल्गोरिथ्म में दे देते हैं।

सहमत: कार्य ValueStringBuilder कार्य के समान है। हां, और यह बहुत ही समान तरीके से हल किया गया था:

फ़ाइल ValueListBuilder.cs

इसे कुंद करने के लिए, ऐसी परिस्थितियां काफी सामान्य हैं। हालाँकि, इससे पहले कि हम इस प्रश्न को दूसरे तरीके से हल करें: हमने एक List बनाई, इसे डेटा के साथ पॉप्युलेट किया और लिंक खो दिया। यदि विधि को अक्सर पर्याप्त कहा जाता है, तो एक दुखद स्थिति पैदा होती है: List वर्ग के कई उदाहरण ढेर पर लटकाए जाते हैं, और उनके साथ जुड़े हुए सरणियों को ढेर पर लटकाते हैं। अब यह समस्या हल हो गई है: कोई अतिरिक्त ऑब्जेक्ट नहीं बनाए जाएंगे। हालाँकि, ValueStringBuilder के मामले में, यह केवल Microsoft प्रोग्रामर के लिए हल किया गया था: वर्ग में एक internal संशोधक है।

उपयोग की शर्तें और नियम

अंत में नए डेटा प्रकार के सार को समझने के लिए, आपको कुछ चीजों को लिखकर, या बेहतर तरीके से, इसके उपयोग के तरीकों को लिखकर "इसके चारों ओर" खेलना होगा। हालाँकि, बुनियादी नियमों को अब सीखा जा सकता है:

• यदि आपकी विधि कुछ आवक डेटा को उसके आकार को बदले बिना संसाधित करेगी, तो आप Span प्रकार पर रोकने का प्रयास कर सकते हैं। यदि इस बफ़र का कोई संशोधन नहीं है, तो ReadOnlySpan प्रकार पर;
• यदि आपका तरीका स्ट्रिंग के साथ काम करेगा, कुछ आंकड़ों की गणना करेगा या स्ट्रिंग को पार्स करेगा, तो आपकी विधि ReadOnlySpan<char> को स्वीकार करना चाहिए । यह बाध्य है: यह एक नया नियम है। आखिरकार, यदि आप एक स्ट्रिंग स्वीकार करते हैं, तो आप किसी को आपके लिए एक विकल्प बनाने के लिए मजबूर करते हैं
• यदि आपको विधि के काम के हिस्से के रूप में डेटा (जैसे, 10Kb अधिकतम) के साथ एक काफी छोटा सरणी बनाने की आवश्यकता है, तो आप आसानी से Span<TType> buf = stackalloc TType[size] का उपयोग करके इस तरह के एक सरणी को व्यवस्थित कर सकते हैं। हालांकि, निश्चित रूप से, TType केवल एक सार्थक प्रकार होना चाहिए, जैसा कि stackalloc केवल सार्थक प्रकारों के साथ काम करता है।

अन्य मामलों में, यह Memory या क्लासिक डेटा प्रकारों का उपयोग करने के लिए एक करीब से देखने के लायक है।

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

इसके अलावा, मैं इस बारे में बात करना चाहूंगा कि स्पैन कैसे काम करता है और इसके बारे में क्या उल्लेखनीय है। और इसके बारे में बात करने के लिए कुछ है: डेटा प्रकार स्वयं दो संस्करणों में विभाजित है: .NET कोर 2.0+ और बाकी सभी के लिए।

Span.Fast.cs, .NET कोर 2.0 फ़ाइल

 public readonly ref partial struct Span<T> { ///    .NET    internal readonly ByReference<T> _pointer; ///      private readonly int _length; // ... } 

फ़ाइल ??? [Decompiled]

 public ref readonly struct Span<T> { private readonly System.Pinnable<T> _pinnable; private readonly IntPtr _byteOffset; private readonly int _length; // ... } 

बात यह है कि बड़े .NET फ्रेमवर्क और .NET कोर 1. * में विशेष रूप से संशोधित कचरा कलेक्टर (.NET कोर 2.0+ के संस्करण के विपरीत) नहीं है और इसलिए एक अतिरिक्त सूचक के साथ खींचने के लिए मजबूर किया जाता है: बफर की शुरुआत काम करते हैं। यही है, यह पता चलता है कि Span आंतरिक रूप से .NET प्लेटफ़ॉर्म की प्रबंधित वस्तुओं के साथ अप्रबंधित के रूप में काम करता है। संरचना के दूसरे संस्करण के इनसाइड पर एक नज़र डालें: तीन क्षेत्र हैं। पहला फ़ील्ड प्रबंधित ऑब्जेक्ट का संदर्भ है। दूसरा डेटा बफ़र की शुरुआत पाने के लिए बाइट्स में इस ऑब्जेक्ट की शुरुआत से ऑफसेट है (लाइनों में यह char वर्णों के साथ एक बफर है, सरणियों में यह सरणी डेटा के साथ एक बफर है)। और अंत में, तीसरा फ़ील्ड इस बफर के तत्वों की संख्या है जो एक के बाद एक स्टैक किए गए हैं।

उदाहरण के लिए, स्ट्रिंग्स के लिए Span नौकरी लें:

फ़ाइल coreclr :: src / System.PStreet.CoreLib / share / System / MemoryExtensions.Fast.cs

 public static ReadOnlySpan<char> AsSpan(this string text) { if (text == null) return default; return new ReadOnlySpan<char>(ref text.GetRawStringData(), text.Length); } 

जहाँ string.GetRawStringData() इस प्रकार है:

फ़ील्ड की परिभाषा फ़ाइल coreclr :: src / System.PStreet.CoreLib / src / System / String.CoreCLI.cs

GetRawStringData परिभाषा फ़ाइल coreclr :: src / System.PStreet.CoreLib / साझा / प्रणाली /ring.cs

 public sealed partial class String : IComparable, IEnumerable, IConvertible, IEnumerable<char>, IComparable<string>, IEquatable<string>, ICloneable { // // These fields map directly onto the fields in an EE StringObject. See object.h for the layout. // [NonSerialized] private int _stringLength; // For empty strings, this will be '\0' since // strings are both null-terminated and length prefixed [NonSerialized] private char _firstChar; internal ref char GetRawStringData() => ref _firstChar; } 

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

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

वापसी मूल्य के रूप में स्पैन [टी]

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

 unsafe void Main() { var x = GetSpan(); } public Span<byte> GetSpan() { Span<byte> reff = new byte[100]; return reff; } 

तब सब कुछ बेहद तार्किक और अच्छा लगता है। हालांकि, यह एक निर्देश को दूसरे के साथ बदलने के लायक है:

 unsafe void Main() { var x = GetSpan(); } public Span<byte> GetSpan() { Span<byte> reff = stackalloc byte[100]; return reff; } 

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

इसलिए, मुझे आशा है कि आपने सोचा था, अनुमानों और मान्यताओं का निर्माण किया था, और शायद इसका कारण भी समझा। यदि हां, तो मैंने व्यर्थ के कोगों पर थ्रेड स्टैक पर अध्याय को चित्रित नहीं किया। आखिरकार, इस तरह से काम पूरा करने वाले तरीके के स्थानीय पैरामेंट्स को एक लिंक दिया गया, आप दूसरी विधि को कॉल कर सकते हैं, इसके खत्म होने की प्रतीक्षा कर सकते हैं और x [0.99] के माध्यम से इसके स्थानीय चर पढ़ सकते हैं।

, , , , : CS8352 Cannot use local 'reff' in this context because it may expose referenced variables outside of their declaration scope : , , , .

Span<T> , . , use cases .

पूरी किताब का लिंक

• सीएलआर बुक: गिटहब
• 0.5.0 पुस्तकें, PDF: GitHub रिलीज़ जारी करें