According to the documentation:
Fills the internal buffer with the specified number of bytes read from the stream.
What does this mean (what's the internal buffer?)?
views:
28answers:
3
A:
The BinaryReader has an internal buffer so that it doesn't need to perform as many small reads on the underlying stream, especially also when reading character data which may need some lookahead. You shouldn't need to call this manually.
Lucero
2010-10-17 20:08:57
So I'm wondering about why it's protected instead of private.
Alofons
2010-10-17 20:13:31
You're not alone: http://www.pcreview.co.uk/forums/thread-1225604.php - I guess they first wanted to make it easier to extend and then stopped halfway or didn't undo everything.
Lucero
2010-10-17 20:17:17
A:
Notice that the method is declared as protected.
As such, it is only of interest if you want to create a class that inherits from BinaryReader, which you seldom need to do.
Lasse V. Karlsen
2010-10-17 20:14:21
...but even then it's pretty useless because you don't have any control over the internal buffer, even when overriding that method. I agree with Alofons on that.
Lucero
2010-10-17 20:21:02
I agree, it doesn't make much sense. I would think that it might be useful to be able to call this before you read a big object consisting of many smaller pieces, by ensuring that halfway through the object-reading it won't have to fill the buffer, and thus you could pre-load the buffer. However, as you say, you have no control over the size of the buffer, or anything really, so most likely this is an artifact of someone thinking the class should be extendable, and then not completing the job.
Lasse V. Karlsen
2010-10-17 20:28:11
A:
It looks like the main aim here is to allow you to have a convenient method to ensure that you have a block of data locally; for example, when reading a "double" you would (typically) want 8 bytes. This method wraps up:
- checking if the internal buffer already has enough
- looping over 'Read' as necessary
- checking for EOF (and erroring)
- guarding for overrun
- handling buffer-management, such as either block-copying the data backwards periodically, or handling the various indices for a cyclic buffer
However, it seems unlikely you would need to call it externally, unless you were reading a small 'byte[]'
As for the internal buffer; simply, when deserializing you:
- want to minimise calls to "Read"
- often need to peek-ahead more than 1 byte (tricky without a buffer)
- regularly want operations on small 'byte[]' (via BitConverter, for example)
So just work
Marc Gravell
2010-10-17 20:35:05