Using Keyword Dispose and GC

[Mehul Patel]

Our .Net team have been pondering about using keyword.

We are using streams FileStream and BufferedStream. We use using
keyword at FileStream, and not BufferedStream which wraps FileStream.
So bunch of people said what if exception occurs buffered stream is
not closed.

My Argument is over advantages of using 'Using' keyword.

First Advantage being -- Using used for Dispose (Deterministic
Finalization) to free resources earlier, than later. Dispose and Close
do the same thing. This statement is valid, and is verified by
numerous sources (msdn,books,blogs,newsgroups).

Second Advantage being all objects in using bracket will have priority
in Gargbage collection ! - Is this statement valid?

If file stream is grabage collected, there is no need to use Using
keyword on BufferedStream -- Is this statement valid?.

Pl shed some light on this.
Thanks Very much.
Mehul.

 

[Jon Skeet [C# MVP]]

[I don't think it was worth cross-posting this *quite* so widely, btw.
There's also no such group as microsoft.public.dotnet.csharp.general]

Our .Net team have been pondering about using keyword.

We are using streams FileStream and BufferedStream. We use using
keyword at FileStream, and not BufferedStream which wraps FileStream.
So bunch of people said what if exception occurs buffered stream is
not closed.

I would expect that the buffered stream wouldn't actually have any
unmanaged resources itself. On the other hand, it wouldn't hurt to be
sure, and it would add to consistency.

My Argument is over advantages of using 'Using' keyword.

First Advantage being -- Using used for Dispose (Deterministic
Finalization) to free resources earlier, than later. Dispose and Close
do the same thing. This statement is valid, and is verified by
numerous sources (msdn,books,blogs,newsgroups).
Yes.

Second Advantage being all objects in using bracket will have priority
in Gargbage collection ! - Is this statement valid?

No, I don't believe that's valid at all.

If file stream is grabage collected, there is no need to use Using
keyword on BufferedStream -- Is this statement valid?.

It's *probably* okay, but I would personally use the using statement
with the BufferedStream as well. In fact, I'd probably just have one:

using (BufferedStream stream = new BufferedStream (new FileStream(...))
{
....
}

Out of interest, are you sure the BufferedStream is helping you? I
*thought* FileStreams were already buffered, although I could be wrong.

 

[David Browne]

[I don't think it was worth cross-posting this *quite* so widely, btw.
There's also no such group as microsoft.public.dotnet.csharp.general]

Our .Net team have been pondering about using keyword.

We are using streams FileStream and BufferedStream. We use using
keyword at FileStream, and not BufferedStream which wraps FileStream.
So bunch of people said what if exception occurs buffered stream is
not closed.

I would expect that the buffered stream wouldn't actually have any
unmanaged resources itself. On the other hand, it wouldn't hurt to be
sure, and it would add to consistency.

It is an error to close the underlying stream before the BufferedStream,
since any buffered data will not have been written to the file. You should
use the using block on the BufferedStream. BufferedStream.Close calls
BufferedSteram.Flush then Stream.Close.

.. . .

using (BufferedStream stream = new BufferedStream (new FileStream(...))
{
...
}
Exactly.


Out of interest, are you sure the BufferedStream is helping you? I
*thought* FileStreams were already buffered, although I could be wrong.

FileStream is not buffered in managed memory, it just calls WriteFile. But
NTFS does various things to make writing files fast. That being said, the
priority is to get written data safely on disk, so if you have a lot of very
small writes I suppose a BufferedStream could improve your performance.

David

 

[Jon Skeet [C# MVP]]

It is an error to close the underlying stream before the BufferedStream,
since any buffered data will not have been written to the file. You should
use the using block on the BufferedStream. BufferedStream.Close calls
BufferedSteram.Flush then Stream.Close.

Ah, very true. I'd forgotten about the flush issue...