I have installed the Visual C# 2005 Code Snippets, and the snippets
for file handling use StreamReader and StreamWriter, instead of
System.IO.File.*. VB 2005 code snippets don't use these. Why are
they suggesting the use of these classes instead of the fundamental
File methods? Are they better? I thought code snippets were supposed
show things in the easy / simple way.

What do you guys think? What should a beginner learn to do when
learning to read / write files?

Zytan

> the snippets
> for file handling use StreamReader and StreamWriter

And they even use the using-statement! Which is hard to grasp quickly
(especially when the docs show it using a resource created before the
using statement block, which is strange since it is supposed to
destruct that object at the end of the block, but how can it do this
when the object it is *still in scope* after the using statement
block!?)

> I thought code snippets were supposed
> show things in the easy / simple way.

So, these snippets are certainly not the easiest way.

Zytan

Zytan wrote:
> I have installed the Visual C# 2005 Code Snippets, and the snippets
> for file handling use StreamReader and StreamWriter, instead of
> System.IO.File.*. VB 2005 code snippets don't use these. Why are
> they suggesting the use of these classes instead of the fundamental
> File methods? Are they better? I thought code snippets were supposed
> show things in the easy / simple way.
>
> What do you guys think? What should a beginner learn to do when
> learning to read / write files?

I do not have code snippets, but I think you can use
the following rule of thumb:

*Stream for binary files
*Writer/*Reader for text files (ignoring BinaryReader/BinaryWriter)

*Writer/*Reader are additional functionality on top of *Stream.

Arne

Zytan wrote:
>> the snippets
>> for file handling use StreamReader and StreamWriter
>
> And they even use the using-statement! Which is hard to grasp quickly
> (especially when the docs show it using a resource created before the
> using statement block, which is strange since it is supposed to
> destruct that object at the end of the block, but how can it do this
> when the object it is *still in scope* after the using statement
> block!?)

At the end of the using block the Dispose method is called
which will release all unmanaged resources. It is not
"destructed".

Arne

Most of the File and FileStream class' methods deal with arrays of bytes, so
one can assume that File is good for binaries. StreamReader/Writer can read
and write strings as well as bytes, so it's useful when working with text
files, especially large ones.

File's methods can read and write text from and to a file, but they do it
from a pre-allocated buffer or from a pre-allocated array of strings. And
they process the whole file at once. When you need to read a huge text file,
you can allocate a gigabyte-size string and read into it using File's
method. But would you prefer that to multiple calls to
StreamReader.ReadLine() ? With streams you can process large files and not
require lots of memory.

"Zytan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have installed the Visual C# 2005 Code Snippets, and the snippets
> for file handling use StreamReader and StreamWriter, instead of
> System.IO.File.*. VB 2005 code snippets don't use these. Why are
> they suggesting the use of these classes instead of the fundamental
> File methods? Are they better? I thought code snippets were supposed
> show things in the easy / simple way.
>
> What do you guys think? What should a beginner learn to do when
> learning to read / write files?
>
> Zytan
>

Thus wrote Zytan,

> I have installed the Visual C# 2005 Code Snippets, and the snippets
> for file handling use StreamReader and StreamWriter, instead of
> System.IO.File.*. VB 2005 code snippets don't use these. Why are
> they suggesting the use of these classes instead of the fundamental
> File methods? Are they better? I thought code snippets were supposed
> show things in the easy / simple way.

At the end of the day, you're always dealing with either a TextReader/TextWriter
or a Stream. Many of File's methods are convenience APIs that wrap or produce
streams and writers. It's mostly a matter of taste.


Cheers,
--
Joerg Jooss
news-(E-Mail Removed)

> At the end of the using block the Dispose method is called
> which will release all unmanaged resources. It is not
> "destructed".

Ok, I am thinking that destructed = dispose. What is the difference?
When I write a destructor, and it is run, this is the object being
destructed, right?

http://msdn2.microsoft.com/en-us/library/yh598w02.aspx
shows this example:

Font font2 = new Font("Arial", 10.0f);
using (font2)
{
// use font2
}

It seems to me that font2 can still be used after the using statement
block. So what happens? Is the object destructed / disposed (sorry,
I don't know the difference), and font2 = null?

Zytan

> File's methods can read and write text from and to a file, but they do it
> from a pre-allocated buffer or from a pre-allocated array of strings. And
> they process the whole file at once. When you need to read a huge text file,
> you can allocate a gigabyte-size string and read into it using File's
> method. But would you prefer that to multiple calls to
> StreamReader.ReadLine() ? With streams you can process large files and not
> require lots of memory.

Ah, so this is the difference. For me, I think whatever files I'll be
reading, I need them in memory all at once. So, it shouldn't matter.
For example, I could use:

string[] s = System.IO.File.ReadAllLines(path);

And, yes, it means s now stores the entire file, all at once, into
memory. But, I think this is ok for small files.

Thanks for the explanation, this is exactly what I wanted to know.

Zytan

> At the end of the day, you're always dealing with either a TextReader/TextWriter
> or a Stream. Many of File's methods are convenience APIs that wrap or produce
> streams and writers. It's mostly a matter of taste.

Ok, thanks. So, I'll do it my way, and if I ever need to handle a
file as a stream of bytes (I don't think I do), I'll look into the
StreamReader/Writer.

Zytan

Zytan <(E-Mail Removed)> wrote:
> > At the end of the using block the Dispose method is called
> > which will release all unmanaged resources. It is not
> > "destructed".
>
> Ok, I am thinking that destructed = dispose. What is the difference?
> When I write a destructor, and it is run, this is the object being
> destructed, right?

Well, it's being finalized. It *could* still survive, if something
during finalization promotes it - but generally, the object is about to
be garbage collected.

Being *disposed*, however, is very different - that's just calling the
Dispose method. After Dispose has been called, an object *may* still be
perfectly usable, and disposing of it doesn't affect garbage
collection, although calling Dispose will often suppress the finalizer
if there is one (because finalizers generally do the same thing).

> http://msdn2.microsoft.com/en-us/library/yh598w02.aspx
> shows this example:
>
> Font font2 = new Font("Arial", 10.0f);
> using (font2)
> {
> // use font2
> }
>
> It seems to me that font2 can still be used after the using statement
> block. So what happens? Is the object destructed / disposed (sorry,
> I don't know the difference), and font2 = null?

font2 still refers to the same object, it's just that Dispose() has
been called on it.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too