Re: Stream IO - Correct usage of Set_Index

[dennison@telepath.com]

In article <7bmka1$mso$1@whatsit.aston.ac.uk>,
  gaukrogi@aston.ac.uk (Rofi) wrote:
> In article <7bh1me$v4t$1@nnrp1.dejanews.com>,
> 	dennison@telepath.com writes:
> > what I'm currently using them for is to keep track of previous locations in
a
> > stream that I may want to go back to.
>
> Like that idea.  Errrmm (thinking), I'm wondering whether it would be
> possible to actually store positions within a file in the file for use next
> time I access the file.  As I know what positions I'm likely to want to go
> to then this could be a nice solution.  Will have to try that one out.

That's one possibility. You could also make a "initial pass" through the
stream, taking note of important indexes, before your real reads begin.

> > So what if you *do* need to know how big every entry in a stream is? Simple;
> > create your own stream that keeps track of that information. (more info on
> > doing that is available upon request).
>
> Request: more info on doing that :-) (please)
> I don't know whether it will the be the best solution for my current problem
> but if you have more info easily to hand it would be greatly appreciated.

It is a bit more painful than one would think at first blush. For one thing
you have to define what you consider an "entry" in the stream. On the stream
side you will probably see one Write call for every scalar subobject
contained in an object passed into 'Write. That means every character in a
string will cause one stream Write call! If you tack a length onto the front
of everything passed into the stream's Write, you may end up with more
overhead than data. So you have to have some way to group all the data from
one data structure that you care about on the 'Write side.

The way I solved this problem (after copious advice from c.l.a., thank you
everyone) is to add two calls to the stream interface that clients are to put
around every 'Write and 'Output. The first call places an integer marker in
the stream, and the second replaces the previous marker with the delta in
stream elements from that marker to the end of the stream. There also need to
be calls around 'Read and 'Input so your stream can discard those markers
before they get passed back to the user as data.

Now if I want to implement a Skip_Entry feature for this stream, it could
easily be done by just moving the stream's read pointer forward by the number
of elements stored in the marker it currently points to.

Now odds are that your implementation of file streams doesn't do anything too
goofy (like automatic LZW compression of the data). I haven't tried this, but
you may be able to implement something like this on the 'Write/'Read side, if
you have control of all the code doing the 'Writeing. But that is assuming
Stream_IO.Index and Stream_IO.Set_Index have some meaning during output
operations, which I have not checked into. I said, this method would not be
portable. A new version of your same compiler might even break it, if it were
to change the file stream implementation for some reason.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own