"David Abrahams" <dave@boost-consulting.com> wrote in message news:ubrk18u0m.fsf@boost-consulting.com...
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
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.
You lost me here. What positions aren't?
positions that record an offset and a code conversion state.
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.
Do you mean variable-length-character streams?
I mean streams of characters as they are read from a file with a multibyte encoding -- an encoding in which a single character may be represented by a sequence of bytes, possibly of varying length -- before code conversion is performed.
I definitely want to do regular random access on streams of wchar_t, which I suppose are "multibyte".
Random access in wide streams is generally fine. (However, if the wide stream is based on an underlying multibyte stream, and the member function encoding() of the codecvt used to perform the conversion returns a value <= 0, then random-access is rather inefficient.) (Maybe I shouldn't have confused the issues by bringing up code conversion. It is an issue, however, whenever you use pubseekpos, since positions don't exactly correspond to offsets.) The offsetbuf could be defined like this (assuming a narrow stream, for simplicity): class offsetbuf : public streambuf_facade<offset_filter> { public: offsetbuf(std::streambuf& sb, std::streamoff first, std::streamoff last) { set_next(sb); open(offset_filter(first, last)); } }; Here offset_filter is the filter I described before. Jonathan