From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-06-01 05:44:57
Sebastian Redl <sebastian.redl_at_[hidden]> writes:
> Jerry Schwarz wrote:
>> I agree with you that the current streambuf is a mess. If you want to
>> create a new binary_streambuf and build your library on that I
>> wouldn't object. But you didn't do that, you built a library without
>> any other transport mechanism. At heart my suggestion is to have
>> binary_streams built based on some transport mechanism, and have that
>> mechanism (whatever it is) highly visible.
> You're confusing me with the binary_iostreams author. I didn't build any
> Elaborating on my previous post, here's a quick diagram I drew of the
> system I envision.
Your diagram is reasonable. I have several comments about issues
relating to this design, some of which you have suggested:
It needs to be considered how an asynchronous I/O interface will fit
into this framework.
It also needs to be considered how operations like seeking fit into this
For efficiency reasons, particularly in supporting seeking, it is
probably important that buffering filters can be applied directly at the
character level as well as at the byte level.
It is also probably important to support stackable character sources and
sinks in a similar way that stackable byte sources are to be supported.
(For instance, the user may want to use std::vector<character_type> or,
more generally, an iterator range over a sequence of character_type, as
a source of characters.)
-- Jeremy Maitin-Shepard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk