👨🏼‍💼 ✒️ 💐 स्टास अफानसैव। जूनो। Io.Reader / io.Writer पर आधारित पाइपलाइन। भाग 1 🥡 ☀️ 📰

रिपोर्ट में, हम io.Reader / io.Writer की अवधारणा के बारे में बात करेंगे कि इनकी आवश्यकता क्यों है, इन्हें सही तरीके से कैसे लागू किया जाए और इस संबंध में क्या नुकसान मौजूद हैं, साथ ही मानक और कस्टम io.eader / io.Writer कार्यान्वयन के आधार पर पाइपलाइनों के निर्माण के बारे में भी। ।

स्टानिस्लाव अफानसेव (इसके बाद - SA): - शुभ दोपहर! मेरा नाम स्टास है। मैं जूनो कंपनी से मिन्स्क आया था। इस बारिश के दिन आने के लिए धन्यवाद, घर छोड़ने की ताकत मिली।

आज मैं आपके साथ ऐसे विषय पर बात करना चाहता हूं जैसे कि पाइपलाइनों का निर्माण करना io.Reader / io.Writer इंटरफेस पर आधारित है। मैं आज के बारे में बात करने जा रहा हूं, सामान्य तौर पर, io.Reader / io.Writer इंटरफेस की अवधारणा, उनकी आवश्यकता क्यों है, उनका सही तरीके से उपयोग कैसे करें और सबसे महत्वपूर्ण, उन्हें सही तरीके से कैसे लागू किया जाए।

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

शुरू करने से पहले, हमें इस सवाल का जवाब देना चाहिए कि आखिर इन इंटरफेस की आवश्यकता क्यों है? अपने हाथों को ऊपर उठाएं, जो गो के साथ कसकर काम करता है (हर दिन, हर दूसरे दिन) ...

महान! हमारे पास अभी भी एक गो समुदाय है। मुझे लगता है कि आप में से कई ने इन इंटरफेस के साथ काम किया है, उनके बारे में सुना है, कम से कम। आप उनके बारे में भी नहीं जानते होंगे, लेकिन आपको निश्चित रूप से उनके बारे में कुछ सुनना चाहिए था।

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

io.Reader

यह एक बहुत ही सरल इंटरफ़ेस है। इसमें केवल एक विधि शामिल है - पढ़ें विधि। वैचारिक रूप से, io.Reader इंटरफ़ेस कार्यान्वयन एक नेटवर्क कनेक्शन हो सकता है - उदाहरण के लिए, जहां अभी तक कोई डेटा नहीं है, लेकिन वे वहां दिखाई दे सकते हैं:

यह मेमोरी में एक बफर हो सकता है जहां डेटा पहले से मौजूद है और इसे पूरी तरह से पढ़ा जा सकता है। यह एक फाइल डिस्क्रिप्टर भी हो सकता है - हम इस फाइल को टुकड़ों में पढ़ सकते हैं यदि यह बहुत बड़ा है।

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

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

विधि पढ़ें दो मान लौटाता है:

घटाकर बाइट्स की संख्या;
यदि यह हुआ तो एक त्रुटि।

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

Io.Reader - कैसे करें?

रीडर इंटरफ़ेस को संतुष्ट करने के लिए आपके डेटा के लिए दो तरीके हैं।

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

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

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

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

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

प्रलेखन नियम

जैसा कि मैंने कहा, नियमों की सूची, और सामान्य तौर पर प्रलेखन काफी बड़ा है, बड़े पैमाने पर है। 30 लाइनें एक इंटरफ़ेस के लिए पर्याप्त हैं जिसमें केवल तीन लाइनें शामिल हैं।

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

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

Bufio को कुछ भी भरोसा नहीं है - यह बिल्कुल सब कुछ जांचता है। बाइट्स। बफ़र उसे आने वाली हर चीज़ पर भरोसा करता है। अब मैं दिखाऊंगा कि इस संबंध में क्या हो रहा है ...

हम अब तीन संभावित मामलों पर विचार करेंगे - ये तीन कार्यान्वित पाठक हैं। वे काफी सिंथेटिक हैं, समझने के लिए उपयोगी हैं। हम ReadAll सहायक का उपयोग करके इन सभी पाठकों को पढ़ेंगे। उनके हस्ताक्षर स्लाइड के शीर्ष पर प्रस्तुत किए गए हैं:

io.Reader # 1। उदाहरण 1

ReadAll एक सहायक है जो रीडर इंटरफ़ेस के किसी प्रकार के कार्यान्वयन को लेता है, यह सब पढ़ता है और उस डेटा को वापस करता है जिसे वह पढ़ता है, साथ ही एक त्रुटि भी।

हमारा पहला उदाहरण रीडर है, जो हमेशा -1 और एनआईएल को एक त्रुटि के रूप में लौटाएगा, अर्थात् ऐसा एक नकारात्मक। आइए इसे चलाएं और देखें कि क्या होता है:

जैसा कि आप जानते हैं, बिना किसी कारण के घबराहट मूर्खता का संकेत है। लेकिन इस मामले में कौन मूर्ख है - मैं या बाइट। बफ़र - देखने के बिंदु पर निर्भर करता है। जो लोग इस पैकेज को लिखते हैं और जो इसका अनुसरण करते हैं उनके दृष्टिकोण अलग हैं।

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

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

दूसरा "बिंदु" यह है कि स्टैक ट्रेस समझ में नहीं आता है कि क्या हुआ। यह स्पष्ट है कि हम टुकड़ा की सीमाओं से परे चले गए हैं - तो क्या? जब आपके पास ऐसी बहुपरत पाइप होती है और ऐसी त्रुटि होती है, तो यह तुरंत स्पष्ट नहीं होता है कि क्या हुआ। तो मानक पुस्तकालय का bufio भी इस स्थिति में "आतंक" है, लेकिन यह इसे और अधिक खूबसूरती से करता है। वह तुरंत लिखते हैं: “मैंने बाइट्स की एक नकारात्मक संख्या घटा दी। मैंने कुछ और नहीं किया - मुझे नहीं पता कि इसके साथ क्या करना है। "

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

io.Reader # 1। उदाहरण 2

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

वास्तविक जीवन में, ऐसे पाठक बहुत परेशानी का कारण बन सकते हैं। तो, हम इस सवाल पर लौटते हैं कि क्या हमें पाठक पर भरोसा करना चाहिए? उदाहरण के लिए, एक चेक bufio में बनाया गया है: यह क्रमिक रूप से रीडर को 100 बार पढ़ता है - यदि इस तरह के मूल्यों को 100 बार लौटाया जाता है, तो यह केवल NoProgress लौटाता है।

बाइट्स में ऐसा कुछ नहीं है। बफ़र। यदि हम इस उदाहरण को चलाते हैं, तो हमें सिर्फ एक अंतहीन लूप मिलता है (ReadAll बाइट्स का उपयोग करता है। हुड के नीचे बफ़र, रीडर ही नहीं):

io.Reader # 1। उदाहरण 2

एक और उदाहरण। यह काफी सिंथेटिक है, लेकिन समझने के लिए उपयोगी है:

यहां हम हमेशा 1 और शून्य लौटाते हैं। ऐसा लगता है कि यहां कोई समस्या नहीं है - अनुबंध के दृष्टिकोण से सब कुछ कानूनी है। एक अति सूक्ष्म अंतर है: अगर मैं इस उदाहरण को अपने कंप्यूटर पर चलाता हूं, तो यह 30 सेकंड के बाद फ्रीज हो जाएगा ...

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

io.Reader # 2। त्रुटि वापसी

हम रीडर इंटरफ़ेस को लागू करने के लिए दूसरे महत्वपूर्ण नियम पर आते हैं - यह एक त्रुटि वापसी है। प्रलेखन में तीन त्रुटियां बताई गई हैं कि कार्यान्वयन वापस आ जाना चाहिए। उनमें से सबसे महत्वपूर्ण ईओएफ है।

ईओएफ डेटा के अंत का बहुत ही संकेत है, जिसे जब भी डेटा से बाहर किया जाता है, तो कार्यान्वयन वापस आ जाना चाहिए। वैचारिक रूप से, यह सामान्य तौर पर एक गलती नहीं है, बल्कि एक गलती के रूप में की गई है।

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

एक और गलती NoProgress है, जिसके बारे में हमने पहले ही बात की थी। दस्तावेज़ीकरण ऐसा कहता है: यह एक संकेत है कि इंटरफ़ेस लागू किया गया है बेकार है।

आयो.डर # 3

प्रलेखन सही ढंग से त्रुटि वापस करने के लिए मामलों के एक सेट को निर्धारित करता है। नीचे आप तीन संभावित मामलों को देख सकते हैं:

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

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

io.Reader। गलतियां

सामान्य तौर पर, रीडर के अनुसार, ये मुख्य महत्वपूर्ण नियम थे। अभी भी छोटे लोगों का एक सेट है, लेकिन वे इतने महत्वपूर्ण नहीं हैं और ऐसी स्थिति पैदा नहीं करते हैं:

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

दो सबसे लोकप्रिय त्रुटियों की पहचान की:

कभी भी ईओएफ वापस नहीं करता;
लिपटे रीडर में बहुत ज्यादा भरोसा।

फिर, यह मेरे दृष्टिकोण से एक समस्या है। और उन लोगों से जो io पैकेज देख रहे हैं, यह कोई समस्या नहीं है। हम इस बारे में फिर से बात करेंगे।

मैं एक बारीकियों पर लौटना चाहूंगा। देखें:

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

पाठक के अनुसार, मूल रूप से सब कुछ। ये मूल कार्यान्वयन नियम थे।

io.Writer

पाइपलाइनों के दूसरे छोर पर, हमारे पास io.Writer है, जहां हम आमतौर पर डेटा लिखते हैं। एक बहुत ही समान इंटरफ़ेस: इसमें एक विधि (लिखें) भी शामिल है, उनके हस्ताक्षर समान हैं। शब्दार्थ के दृष्टिकोण से, लेखक इंटरफ़ेस अधिक समझ में आता है: मैं कहूंगा कि जैसा सुना जाता है, वैसा ही लिखा जाता है।

लिखने का तरीका एक स्लाइस बाइट लेता है और इसे अपनी संपूर्णता में लिखता है। उसके पास नियमों का एक सेट भी है जिसका पालन करना चाहिए।

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

रीडर और राइटर द्वारा, यह बात है।

Dendrogram

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

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

पाइपलाइन

हमने क्या पाठक, io.Writer के बारे में बात की है। अब पाइपलाइन के निर्माण के लिए मानक पुस्तकालय में मौजूद एपीआई के बारे में बात करते हैं। आइए मूल बातों से शुरू करें। शायद यह किसी के लिए भी दिलचस्प नहीं होगा। हालाँकि, यह बहुत महत्वपूर्ण है।

हम मानक इनपुट स्ट्रीम (स्टडिन से) के डेटा को पढ़ेंगे:

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

अभी हम रीडर में रुचि रखते हैं। हम स्टडिन को उसी रीडऑल हेल्पर का उपयोग करते हुए पढ़ेंगे जो हमने पहले ही उपयोग किया था।

इस सहायक के बारे में एक बारीकियों पर ध्यान देने योग्य है: ReadAll पाठक को अंत तक पढ़ता है, लेकिन यह EOF द्वारा समाप्त होने का निर्धारण करता है, उस अंत के संकेत के अनुसार जिसके बारे में हमने बात की थी।
अब हम स्टडिन से पढ़े जाने वाले डेटा की मात्रा को सीमित करेंगे। ऐसा करने के लिए, मानक पुस्तकालय में LimitedReader का कार्यान्वयन

होता है : मैं चाहूंगा कि आप ध्यान दें कि LimitedReader पढ़ने के लिए बाइट्स की संख्या को कैसे सीमित करता है। कोई यह सोचेगा कि यह कार्यान्वयन, यह आवरण, रीडर में मौजूद हर चीज को घटाता है, जिसे वह लपेटता है, और फिर जितना चाहे उतना देता है। लेकिन सब कुछ अलग तरह से काम करता है ...

LimitedReader ऊपरी सीमा के साथ तर्क के रूप में दिए गए स्लाइस को ट्रिम करता है। और वह इस फसली स्लाइस को रीडर को पास करता है, जो इसे लपेटता है। यह एक स्पष्ट प्रदर्शन है कि कैसे रीड डेटा की लंबाई को io.Reader इंटरफ़ेस कार्यान्वयन में विनियमित किया जाता है।

फ़ाइल के अंत में त्रुटि

एक और दिलचस्प बिंदु: ध्यान दें कि यह कार्यान्वयन कैसे EOF त्रुटि देता है! यहां दिए गए नामित मानों का उपयोग किया जाता है, और वे उन मानों द्वारा निर्दिष्ट किए जाते हैं जो हम लिपटे रीडर से प्राप्त करते हैं।

और अगर ऐसा होता है कि लिपटे रीडर में हमारी ज़रूरत से ज़्यादा डेटा है, तो हम लिपटे रीडर के मूल्यों को निर्दिष्ट करते हैं - उदाहरण के लिए, 10 बाइट्स और शून्य - क्योंकि लिपटे रीडर में अभी भी डेटा है। लेकिन चर n, जो घटता है (प्रायद्वीपीय रेखा में), का कहना है कि हम "नीचे" तक पहुंच गए हैं - जो हमें चाहिए।

अगले पुनरावृत्ति में, ग्राहक को फिर से आना चाहिए - पहली शर्त पर, वह ईओएफ प्राप्त करेगा। यह मामला है कि मैंने उल्लेख किया है।

बहुत जल्द जारी रखने के लिए ...

विज्ञापन का एक सा :)

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या $ 4.99 से डेवलपर्स के लिए अपने दोस्तों के क्लाउड-आधारित VPS की अनुशंसा करके हमें समर्थन दें, आपके द्वारा आविष्कार किया गया एंट्री-लेवल सर्वर का एक अनूठा एनालॉग: VPS (KVM) E5-2697 3 (6 करोड़) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है!डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग सी?

स्टास अफानसैव। जूनो। Io.Reader / io.Writer पर आधारित पाइपलाइन। भाग 1

io.Reader

Io.Reader - कैसे करें?

प्रलेखन नियम

io.Reader # 1। उदाहरण 1

io.Reader # 1। उदाहरण 2

io.Reader # 1। उदाहरण 2

io.Reader # 2। त्रुटि वापसी

आयो.डर # 3

io.Reader। गलतियां

io.Writer

Dendrogram

पाइपलाइन

फ़ाइल के अंत में त्रुटि

विज्ञापन का एक सा :)

More articles: