2011-10-16 20 views
6

यह यहां msdn.microsoft.com/en-us/library/system.io.stream.read.aspx कहता है कि Stream.Read और Stream.Write विधियां दोनों स्ट्रीम में स्थिति/ऑफसेट को स्वचालित रूप से अग्रिम करते हैं यहां उदाहरण क्यों हैं http://msdn.microsoft.com/en-us/library/system.io.stream.read.aspx और http://msdn.microsoft.com/en-us/library/system.io.filestream.read.aspx मैन्युअल रूप से ऑफ़सेट बदल रहा है?स्ट्रीम में ऑफ़सेट सेट करना

क्या आप केवल एक लूप में ऑफसेट सेट करते हैं यदि आप स्ट्रीम के आकार को जानते हैं और इसे 0 पर सेट करते हैं, तो यदि आप आकार को नहीं जानते हैं और बफर का उपयोग नहीं करते हैं?

// Now read s into a byte buffer. 
    byte[] bytes = new byte[s.Length]; 
    int numBytesToRead = (int) s.Length; 
    int numBytesRead = 0; 
    while (numBytesToRead > 0) 
    { 
     // Read may return anything from 0 to 10. 
     int n = s.Read(bytes, numBytesRead, 10); 
     // The end of the file is reached. 
     if (n == 0) 
     { 
      break; 
     } 
     numBytesRead += n; 
     numBytesToRead -= n; 
    } 

और

using (GZipStream stream = new GZipStream(new MemoryStream(gzip), CompressionMode.Decompress)) 
{ 
    const int size = 4096; 
    byte[] buffer = new byte[size]; 
    using (MemoryStream memory = new MemoryStream()) 
    { 
    int count = 0; 
    do 
    { 
     count = stream.Read(buffer, 0, size); 
     if (count > 0) 
     { 
     memory.Write(buffer, 0, count); 
     } 
    } 
    while (count > 0); 
    return memory.ToArray(); 
    } 
} 
+0

... क्या? –

+0

स्ट्रीम में आंतरिक ऑफसेट के बीच एक अंतर है, और जब आप एक बफर और स्ट्रीम के बीच डेटा को पढ़/लिखते हैं, और शायद 2. स्ट्रीम के बारे में देखभाल करने के लिए ऑफसेट/लंबाई की आवश्यकता होती है। – nos

+0

@sehe: अपने ओएस को दोष दें। –

उत्तर

4

संपादित (संपादित प्रश्न के लिए):

कोड के टुकड़े आप सवाल मैं देख रहा हूँ किसी भी स्ट्रीम स्थापित किया जा रहा ऑफसेट में चिपकाया में से कोई भी हैं।

मुझे लगता है कि आप प्राप्त बनाम बाइट पढ़ने के लिए बाइट्स की गणना गलत कर रहे हैं। यह प्रोटोकॉल मजाकिया प्रतीत हो सकता है (आप अनुरोध से कम बाइट क्यों प्राप्त करेंगे?) लेकिन जब आप मानते हैं कि आप उच्च-विलंबता पैकेट उन्मुख स्रोत (सोच: नेटवर्क सॉकेट) से पढ़ रहे हैं तो यह समझ में आता है।

आपको एक विस्फोट (एक टीसीपी पैकेट से) में 6 वर्ण प्राप्त हो रहे हैं और केवल आपके अगले पढ़ने में शेष 4 वर्ण प्राप्त होंगे (जब अगला पैकेट आ गया है)।

संपादित टिप्पणी से अपने linked example के जवाब में:

using (GZipStream stream = new GZipStream(new MemoryStream(gzip), CompressionMode.Decompress)) 
    { 
     // ... snip 

     count = stream.Read(buffer, 0, size); 
     if (count > 0) 
     { 
     memory.Write(buffer, 0, count); 
     } 

ऐसा लगता है कि कोडर अंतर्निहित धारा कार्यान्वयन के बारे में पहले से जानकारी का उपयोग करें, कि stream.Read हमेशा 0 या आकार वापस आ जाएगी का अनुरोध किया। यह मेरे लिए एक जोखिम भरा शर्त की तरह लगता है। लेकिन अगर GZipStream के लिए दस्तावेज़ बताते हैं कि यह ठीक हो सकता है। हालांकि, चूंकि एमएसडीएन नमूने जेनेरिक Stream वैरिएबल का उपयोग करते हैं, इसलिए यह बाइट पढ़ने की सटीक संख्या को जांचने के लिए (रास्ता) अधिक सही है।


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

Stream s = new MemoryStream(); 
    for (int i = 0; i < 100; i++) 
    { 
     s.WriteByte((byte)i); 
    } 
    s.Position = 0; 

दूसरे से जुड़ा हुआ उदाहरण नहीं धारा स्थिति निर्धारित करता है। यदि आपने ऐसा किया होता तो आप आमतौर पर Seek पर कॉल देखते थे। आप ऑफसेट को स्ट्रीम स्थिति के साथ डेटा बफर में भ्रमित कर सकते हैं?

+1

मैं लिखने वाले हिस्से के बारे में बात नहीं कर रहा हूं, मेरा मतलब है कि पढ़ा गया हिस्सा। मैं एमएस उदाहरण की तुलना http://www.dotnetperls.com/decompress – Jonas

+1

@ जोनास के साथ कर रहा था: और मैं भी GZipStream नमूना को संबोधित करता हूं, अब – sehe

+0

ओह, मैं देखता हूं, पढ़ता हूं (बाइट्स, numBytesRead, 10); 'है वास्तव में बाइट बफर के लिए ऑफ़सेट? तो 'numBytesRead' बफर के भीतर स्थिति सेट कर रहा है, स्ट्रीम नहीं। – Jonas

9

ऑफसेट वास्तव में बफर का ऑफ़सेट है, स्ट्रीम नहीं। धाराएं स्वचालित रूप से उन्नत होती हैं क्योंकि उन्हें पढ़ा जाता है।

संबंधित मुद्दे