From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-06-02 16:17:31
"David Abrahams" <dave_at_[hidden]> wrote in message
news:ur7syb23h.fsf_at_boost-consulting.com...
> "Jonathan Turkanis" <technews_at_[hidden]> writes:
>
> > "David Abrahams" <dave_at_[hidden]> wrote in message
> >> The thing I wanted recently was an "offset streambuf", an adapter
> >> for another streambuf that presents an "offset view" (i.e. with
> >> respect to seeking) of the underlying streambuf.
> >
> > This sounds like it might be a job for a 'SeekableFilter' --
something
> > I included support for even though I didn't have any use for it.
The
> > interface for a seekable filter is basically this:
<snip>
> > Here 'next' is the streambuf being filtered. Any number of filters
can
> > be chained.
>
> I didn't really think of this as a "filtering" operation, but
anyway...
Sure, I'm just using 'filtering' as a catch-all term
<snip>
> > What exactly did you want the offset streambuf to do?
>
> I wanted to represent a region of offsets in the underlying
streambuf
> as the whole stream. So, for example,
>
>
> void operate_on_region(streambuf& s)
> {
> region_streambuf s1(s, 500, 1000); // a stream over 500 bytes
of s
> s1.pubseekpos(10); // I probably don't have this call quite
right
> traits::int_type c = s1.sbumpc(); // reads byte 510 from s
> }
This fits nicely into the framework, with one caveat, noted below.
> struct seekable_filter {
> // some typedefs
> streamsize read(char* s, streamsize n, streambuf& next);
> void write(const char* s, streamsize n, streambuf& next);
> streamoff seek(streamoff off, ios_base::seekdir way,
> streambuf& next);
> };
The filter would start by seeking to the first offset. Reads and
writes would delegate to next after adjusting the streamsize argument,
if needed. Seeks using ios_bas::cur would delegate to next, after
checking that they stay within the given bounds. Seeks using
ios_base::beg or ios_base::end would adjust the streamoff argument
before delegating.
The caveat is that seeking with respect to stream positions -- i.e.
values of type traits_type::pos_type rather than
traits_type::off_type -- only works as expected for positions which
are equivalent to integral offsets. Free ranging random access doesn't
make much sense in multibyte streams, anyway. There's a more limited
type of random access which is possible in multibyte streams, in which
you can save a position and go back to it later. I've chosen not to
support this, however.
Jonathan