[boost] Re: Iostreams filter buffering policyleadstoextremelysmallreads.

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-04-21 16:20:46

George M. Garner Jr. wrote:
> Johnathan,
>
> In the interests of  time I think that the most important thing that
> you could do right now is to make
> it easy to declare filtering_xxstream classes with specialized
> indirect_streambuf/direct_streambufs.  It shouldn't be necessary to
> replace the entire plumbing just for me to make the few modifications
> that we have discussed.  At the moment the choice of indirect/direct
> streambuf appears to be hardwired into the streambuf_facade_traits.
> Or perhaps you can explain how to specialize just this class without
> replacing the filter plumbing.

You can't just replace the stream buffers in a chain with arbitrary stream
buffers; they must have special properties in order to work together correctly.
The type of changes you have proposed would best be encapsulted by a "buffering
policy"; in other words, streambuf_facade would be given a second major template
parameter:

    template<typename Component, typename Buffering , ...>
    class streambuf_facade;

The buffering policy would dictate whether buffers are present and the strategry
for making use of the buffers.

I implemented this last summer -- I'd summarize the interface but it's buried
somewhere in my local CVS repository. What I found was that to be sufficiently
general the interface was extremely complex. If your goal is to write a stream
buffer to access a particular device, it's far easier to write it from scratch
than to implement a model of Device and a buffering policy. If your goal is to
produce more efficient filter chains, the ability to specify custom buffering
policies might be an advantage, but my judgement was that the current
two-size-fits-all buffering policy was good enough for the initial release, and
possibly for good.

Rather than adding an aditional policy parameter, I'd rather work on fine-tuning
the two existing policies.

> Regards,
>
> George.

Jonathan