BinaryWriter.Seek() vs BinaryWriter.BaseStream.Seek()

  • Thread starter Thread starter Daniel Goldman
  • Start date Start date
D

Daniel Goldman

Can anyone clarify the practical difference, if any, between
BinaryWriter.Seek() and BinaryWriter.BaseStream.Seek()? Under
what conditions might behavior of the two Seeks differ?

Or, can anyone answer: Why does BinaryWriter have it's
own Seek(), instead of using Seek() of contained Stream?

I am porting a desktop data analysis program to C#, and often
have both BinaryWriter / BinaryReader contain same FileStream.

I guess I should just use BinaryWriter.BaseStream.Seek(), since
it's there, but I'd like to know what is going on. I've read
various docs and books, and did not see the answer.

I know the methods don't override each other. Is the duplication
just a convenience? Is one or the other "preferred", and why?

And why is the offset argument int in one, long in the other??

Thanks,
Daniel Goldman
 
Daniel,

The difference between BinaryWriter.Seek() and
BinaryWriter.BaseStream.Seek() is that the latter flush the data before
repositioning. To be precise the flushing is performed everytime you use the
BaseStream property.

Gabriele
 
Thanks for response. Can you give a reference or how you
know this? Also, do you have answers to my other questions?
 
Hi,

There are two ways that you could use to find out about the details of .NET,
look at the Shared Source CLI
(http://sharedsourcecli.sscli.net/source/browse/sharedsourcecli/) or use a
tool like Reflector for .NET (http://www.aisto.com/roeder/dotnet/).

The Shared Source CLI is described in a Microsoft document as "The
Microsoft® Shared Source CLI Implementation is a file archive containing
working source code for the ECMA-334 (C#) and ECMA-335 (Common Language
Infrastructure, or CLI) standards. These standards together represent a
substantial subset of what is available in the Microsoft .NET Framework. In
addition to the CLI implementation and the C# compiler, the Shared Source
CLI Implementation contains a cornucopia of tools, utilities, additional
Framework classes, and samples. It will build and run on the Microsoft
Windows® XP and the FreeBSD operating systems.".
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/h
tml/mssharsourcecli.asp)

Since the Shared Source CLI and the actual .NET do not share the same code
base, it's better to use Reflector for .NET instead since this is what you
are using anyway to run your programs. The Shared Source CLI could be easier
to read and understand, so you want to keep that in mind just in case.
I know the methods don't override each other. Is the duplication
just a convenience? Is one or the other "preferred", and why?
Click to expand...

I don't know the rationale behind the decision to call the Flush() method
when accessing the OutStream property, but maybe it's to guarantee that the
stream object would be in a consistent state.
And why is the offset argument int in one, long in the other??
Click to expand...

I don't know. BinaryWriter.Seek() accepts an int, but then it performs a
cast to long to comply with the signature of Stream.Seek(). Maybe different
programmers implemented the two classes, and instead of forcing somebody to
change their class they compromised with a cast :-)

Gabriele
 
Thanks very much for teaching me how to fish.

I looked at Reflector for .NET application. Unless I am
misinterpreting, it shows BinaryWriter.Seek() is merely
convenience method, that the behavior is exactly the same as
BinaryWriter.BaseStream.Seek(), assuming OutStream is the
same as BaseStream (I think it is). Here's BinaryWriter.Seek():

public virtual long Seek(int offset, SeekOrigin origin)
{
return this.OutStream.Seek(((long) offset), origin);
}

Kind of kludgy. I guess I know why I never heard back from MS
concerning this issue :) It turns out the same applies to
BinaryWriter.Flush() and BinaryWriter.BaseStream.Flush() -
just a convenience method. Also, I guess I need to explore
possibility of other helpful tools like Reflector. Thanks again.
 
Daniel Goldman said:
Thanks very much for teaching me how to fish.

I looked at Reflector for .NET application. Unless I am
misinterpreting, it shows BinaryWriter.Seek() is merely
convenience method, that the behavior is exactly the same as
BinaryWriter.BaseStream.Seek(), assuming OutStream is the
same as BaseStream (I think it is). Here's BinaryWriter.Seek():

public virtual long Seek(int offset, SeekOrigin origin)
{
return this.OutStream.Seek(((long) offset), origin);
}

Kind of kludgy. I guess I know why I never heard back from MS
concerning this issue :) It turns out the same applies to
BinaryWriter.Flush() and BinaryWriter.BaseStream.Flush() -
just a convenience method. Also, I guess I need to explore
possibility of other helpful tools like Reflector. Thanks again.
Click to expand...

Maybe the current implementation doesn't use any buffering, so there's
no need to actually flush in the Seek implementation - but MS is
basically reserving the right for there to be buffering in there at a
later time, at which point Flush will become more useful and Seek will
do a flush first?
 
Good point. Therefore, I should use BinaryWriter.Seek() and
BinaryWriter.Flush(), the most specific methods, even if
currently identical, since who knows what might be implemented
in future. The difference is now I understand what it going on.

I actually end up liking System.IO a lot, but it took a lot
of re-reading docs and experimentation. I do think there is
a big gap in documentation concerning having multiple objects
contain the same stream, but I think it will work OK. If
anyone could shed light on this, I'd be interested.

I had an initial impression that I might be calling methods
on FileStream, but I have given up on that notion (until someone
points out what I'm missing). Instead, I always use BinaryWriter,
BinaryReader, StreamReader, or StreamWriter.

Initially, I was irritated at lack of scanf-type capability,
but I ended up revising my internal file formats into binary
formats, and rewriting my C file reading functions, and it's
all cleaner. I still use fscanf and sscanf in C utilities for
importing files with irregular text formats, where it is handy.
 
Back
Top