Using a FileStream for Random Access

[TC]

I just noticed that the Stream class has a Seek method, which implies that a
FileStream object can be used to manipulate a random-access file. Before
now, I assumed that a Stream, as its name implies, could only stream
sequential data.

Are there any advantages / disadvantages to using a FileStream to manage a
random access file, as opposed to using FileOpen, FilePut, and FileGet? I am
thinking specifically about performance advantages -- is the FileStream
efficient at jumping from point to point in a file?
-TC

[Tom Shelton]

In article <8fQqc.33140$bS1.10862@okepread02>, TC wrote:

I just noticed that the Stream class has a Seek method, which implies that a
FileStream object can be used to manipulate a random-access file. Before
now, I assumed that a Stream, as its name implies, could only stream
sequential data.

Are there any advantages / disadvantages to using a FileStream to manage a
random access file, as opposed to using FileOpen, FilePut, and FileGet? I am
thinking specifically about performance advantages -- is the FileStream
efficient at jumping from point to point in a file?
-TC

All of the native streams are faster then the FileXXX funtions. The
problem comes in calculating the offset - since you can't use fixed size
structures ;)

--
Tom Shelton [MVP]

[TC]

Tom,

That is odd. Before you mentioned that limitation, I had observed that
VB.NET offers many more operations on streams than it does on files opened
with FileOpen. But you are right; BinaryWriter cannot write a variable of a
fixed-length structure, even though FilePut can. Do you think there is a
good reason for this discrepancy? Or do you suppose it was an oversight?

-TC
"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:uP*************@tk2msftngp13.phx.gbl...

All of the native streams are faster then the FileXXX funtions. The
problem comes in calculating the offset - since you can't use fixed size
structures ;)

--
Tom Shelton [MVP]

[Jay B. Harlow [MVP - Outlook]]

TC,
If I needed to write a structure to a BinaryWriter I would simply implement
a form of binary serialization that wrote to or read from a BinaryStream,
similar to the technique discussed in the following article.

http://msdn.microsoft.com/library/de...rp09182003.asp

The example is in C#, however it should be easily converted to VB.NET, post
if you need help.
Remember in .NET it is very hard to get a 'fixed-length structure' where
that structure includes a String, as strings by definition are variable
length! (as they are objects). VB.NET supports fixed-length strings via an
attribute.

Also seeing as normal .NET Binary Serialization supports serializing any
..NET Class or Structure of any size or shape, it would IMHO be
duplication...

Hope this helps
Jay
"TC" <v@x.z> wrote in message news:eKTqc.33326$bS1.15129@okepread02...

Tom,

That is odd. Before you mentioned that limitation, I had observed that
VB.NET offers many more operations on streams than it does on files opened
with FileOpen. But you are right; BinaryWriter cannot write a variable of a fixed-length structure, even though FilePut can. Do you think there is a
good reason for this discrepancy? Or do you suppose it was an oversight?

-TC
"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:uP*************@tk2msftngp13.phx.gbl...

All of the native streams are faster then the FileXXX funtions. The
problem comes in calculating the offset - since you can't use fixed size
structures ;)

--
Tom Shelton [MVP]

[TC]

Jay,

Thank you for the suggestion. Actually, my last post was misleading -- In my
current project, I do not need to store fixed-length structures. I was
merely responding to Tom's comment about structures, which was deserving of
thought.

In fact, my current project deals with fixed-length binary objects. I should
have no trouble writing them to a stream with the BinaryWriter.Write(
Byte() ) method. I'm trying to stay away from serialization because it isn't
compatible with random-access storage, and simply serializing everything in
one sequential file, while easy to code, doesn't support the data-retrieval
speed I require.
Take it easy.
-TC
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...

TC,
If I needed to write a structure to a BinaryWriter I would simply implement a form of binary serialization that wrote to or read from a BinaryStream,
similar to the technique discussed in the following article.

http://msdn.microsoft.com/library/de...rp09182003.asp
The example is in C#, however it should be easily converted to VB.NET, post if you need help.
Remember in .NET it is very hard to get a 'fixed-length structure' where
that structure includes a String, as strings by definition are variable
length! (as they are objects). VB.NET supports fixed-length strings via an
attribute.

Also seeing as normal .NET Binary Serialization supports serializing any
.NET Class or Structure of any size or shape, it would IMHO be
duplication...

Hope this helps
Jay
"TC" <v@x.z> wrote in message news:eKTqc.33326$bS1.15129@okepread02...

Tom,

That is odd. Before you mentioned that limitation, I had observed that
VB.NET offers many more operations on streams than it does on files opened with FileOpen. But you are right; BinaryWriter cannot write a variable

of a

fixed-length structure, even though FilePut can. Do you think there is a
good reason for this discrepancy? Or do you suppose it was an oversight?

-TC
"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:uP*************@tk2msftngp13.phx.gbl...

All of the native streams are faster then the FileXXX funtions. The
problem comes in calculating the offset - since you can't use fixed size structures ;)

--
Tom Shelton [MVP]

[Jay B. Harlow [MVP - Outlook]]

TC,
I realize you were did not ask the original question, however I was
answering your questions:

Do you think there is a
good reason for this discrepancy? Or do you suppose it was an oversight?

The "good reason" is binary serialization, so no it is not an oversight.

Hope this helps
Jay

"TC" <v@x.z> wrote in message news:shUqc.33529$bS1.3556@okepread02...

Jay,

Thank you for the suggestion. Actually, my last post was misleading -- In my current project, I do not need to store fixed-length structures. I was
merely responding to Tom's comment about structures, which was deserving of thought.

In fact, my current project deals with fixed-length binary objects. I should have no trouble writing them to a stream with the BinaryWriter.Write(
Byte() ) method. I'm trying to stay away from serialization because it isn't compatible with random-access storage, and simply serializing everything in one sequential file, while easy to code, doesn't support the data-retrieval speed I require.
Take it easy.
-TC
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...

TC,
If I needed to write a structure to a BinaryWriter I would simply

implement

a form of binary serialization that wrote to or read from a BinaryStream,

similar to the technique discussed in the following article.

http://msdn.microsoft.com/library/de...rp09182003.asp

The example is in C#, however it should be easily converted to VB.NET,

post

if you need help.
Remember in .NET it is very hard to get a 'fixed-length structure' where
that structure includes a String, as strings by definition are variable
length! (as they are objects). VB.NET supports fixed-length strings via an attribute.

Also seeing as normal .NET Binary Serialization supports serializing any
.NET Class or Structure of any size or shape, it would IMHO be
duplication...

Hope this helps
Jay
"TC" <v@x.z> wrote in message news:eKTqc.33326$bS1.15129@okepread02...

Tom,

That is odd. Before you mentioned that limitation, I had observed that
VB.NET offers many more operations on streams than it does on files

opened with FileOpen. But you are right; BinaryWriter cannot write a variable of

a

fixed-length structure, even though FilePut can. Do you think there is

a good reason for this discrepancy? Or do you suppose it was an oversight?
-TC
"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:uP*************@tk2msftngp13.phx.gbl...
>
> All of the native streams are faster then the FileXXX funtions. The
> problem comes in calculating the offset - since you can't use fixed

size > structures ;)
>
> --
> Tom Shelton [MVP]