471,350 Members | 1,372 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,350 software developers and data experts.

System.IO - Rationalle for Deciding Which Members To Use

I'd like to know the rationalle some of you use for deciding which members
of System.IO you use to do your file I/O. It appears that there are many
ways to accomplish any [even basic] task (reading from a text file, for
example). Did the framework designers have any particular *intention* for
how we're supposed to do these basic tasks? Just looking for the "pit of
success" in System.IO if there is one.

For example, when a developer wants to open a text file, there are many ways
to do this... open a StreamReader or FileStream... either explicitly, or
have a FileStream returned by the static File.Open method... just for
starters.

Thanks.
Jul 10 '07 #1
2 1197
On Tue, 10 Jul 2007 16:19:05 -0700, Fred Mertz <A@B.COMwrote:
[...]
For example, when a developer wants to open a text file, there are many
ways
to do this... open a StreamReader or FileStream... either explicitly, or
have a FileStream returned by the static File.Open method... just for
starters.
It depends on how you want to access the file.

If you are dealing with a text file as just plain text, you should use
StreamReader, since that's specifically designed to deal with text i/o.
(I don't recall if using a TextReader-based class like StreamReader also
handles text encoding conversions, but it might and if so that's an
obvious reason why you'd use that instead of a FileStream directly).

If you want to treat the text file as a binary stream for some reason,
then use just use the basic FileStream. Note that this isn't an either/or
thing anyway...StreamReader is a text reader that reads from a stream.
FileStream is what actually opens the file for reading, whether you
provide it explicitly or have StreamReader create it for you, and you need
it whether you use StreamReader or not.

IMHO, you should use the higher-level classes whenever possible, and use
the lower-level classes that require more explicit code on your own part
only when there is no higher-level class that does what you want.

As far as creating a FileStream explicitly, or getting one implicitly from
File.Open() goes, the File.Open() method is a nice convenience, and you
should use it if you like. The File class does not exist solely for
opening files, and the FileStream class can be constructed by a wide
variety of alternatives to specifying the filename. However, just because
File.Open() exists, that's not a reason to eliminate using a filename as a
possible constructor for FileStream, and likewise, just because you can
instantiate a FileStream directly, that's not a reason that the File class
-- which includes all sorts of other file access helper methods -- should
not also offer a simplified file open method.

To me, it is natural that there will be some overlap between classes.
Especially in a framework where a major design goal is to simplify life
for the programmer, I don't see anything wrong with different classes
providing different-but-equivalent methods for doing things. IMHO, the
File class would be less useful without Open() and the FileStream class
would be less useful without filename constructors. So what if in both
classes, those things do the same thing? In fact, I suspect that
File.Open() just uses the FileStream class constructors that take a
filename. The method is there for your convenience, nothing more.

Pete
Jul 10 '07 #2
Fred Mertz wrote:
I'd like to know the rationalle some of you use for deciding which members
of System.IO you use to do your file I/O. It appears that there are many
ways to accomplish any [even basic] task (reading from a text file, for
example). Did the framework designers have any particular *intention* for
how we're supposed to do these basic tasks? Just looking for the "pit of
success" in System.IO if there is one.

For example, when a developer wants to open a text file, there are many ways
to do this... open a StreamReader or FileStream... either explicitly, or
have a FileStream returned by the static File.Open method... just for
starters.
I would use:
* StreamReader/StreamWriter for text files
* BinaryReader/BinaryWriter wrapped around FileStream for sequential
binary files
* FileStream for random access binary files

And I would never use the "VB style" File Open.

Arne
Jul 11 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

19 posts views Thread by Nicolas Pernetty | last post: by
1 post views Thread by Thomas | last post: by
2 posts views Thread by Howard Swope | last post: by
3 posts views Thread by PB | last post: by
2 posts views Thread by monomaniac21 | last post: by
reply views Thread by merve | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.