"David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7syb23h.fsf@boost-consulting.com...
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
"David Abrahams" <dave@boost-consulting.com> 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