There are two types of
FileStream constructors—those for interop scenarios, and the “normal”
ones. The “normal” ones take a string for the file path, while the interop
ones require either an
IntPtr or a
SafeFileHandle. These wrap a Win32 file
handle that you have retrieved from somewhere. (If you’re not already
using such a thing in your code, you don’t need to use these versions.)
We’re not going to cover the interop scenarios here.
If you look at the list of constructors, the first thing you’ll
notice is that quite a few of them duplicate the various permutations of
FileMode overloads we had on
You’ll also notice equivalents with one extra
int parameter. This allows you to provide a hint
for the system about the size of the internal buffer you’d like the stream
to use. Let’s look at buffering in more detail.
Many streams provide buffering. This means that when you read and write, they actually use an intermediate in-memory buffer. When writing, they may store your data in an internal buffer, before periodically flushing the data to the actual output device. Similarly, when you read, they might read ahead a whole buffer full of data, and then return to you only the particular bit you need. In both cases, buffering aims to reduce the number of I/O operations—it means you can read or write data in relatively small increments without incurring the full cost of an operating system API call every time.
There are ...