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