From: Robert Ramey (ramey_at_[hidden])
Date: 2003-06-08 13:51:37
This a very ripe subject
My interest stems from my efforts regarding a serialization library. I have
had occasion to consider alternatives in this light. I have looked at
Jeffs compression streambuf. I think its interesting, useful and nicely done.
Given this, maybe you should set your sights even higher.
I think it would be more interesting if the following were considered
a) composability - suppose I have an encryption facility and a
compression facility. I would like to be able to make a
streambuf the compresses thhen encryrpts or vice versa.
b) suppose I add other facilities such as escaping/unescaping
ascii characters, convert to/from wide characters, etc. I should
be able to compose these in an arbitray way.
c) this suggests to me:
i) a implemention set of composable iterator adaptors.
ii) a streambuf that can filter input/output through an itererator adaptor. This
MIGHT be implemented as a codecvt facet that takes an interator adaptor
as an argument.
d) This would have the advantage that the conversion facilities would be useful
way beyond streambuf
e) currently, the new iterator adaptor package doesn't include an example that
is suitable for use as a basis for such "conversion" or transformational adaptors.
But its not hard to make one.
To summarize, I would like see the concept of "adaptable sequence" factored
out of streambuf and a streambuf built that can use any "adaptable sequence".
Jeff Garland wrote
>Jonathon T. wrote:
>> I have several class templates for producing standard streambufs based on
>> classes with read, write and seek functions (or a suitable subset thereof.)
>> I have used them successfully to access tcp connections, cryptographic
>> routines, OLE compound documents, zip files, etc.
>> There are templates istreambuf and ostreambuf which perform either input or
>> output exclusively, a template double_streambuf which behaves like an
>> istreambuf glued to an ostreambuf, and a template bidirectional_streambuf
>> which performs input and output using a single shared buffer with a single
>> repositionable file pointer.
>> In addition, template parameters can be used to specify code conversion and
>> to turn off buffering, and a contained error object can be used to customize
>> exception throwing.
>> I there is any interest, I will post them at the vault.
>I have an interest in this (sorry for the slow response) for a couple reasons.
>1) I'd be interested in how this fits with the Boost Socket initiative
>2) I've written something similar for zip files, but looks like you may have
>a more general solution -- a toolkit for creating new streambuf types. If
>this is the case, it would be very handy.