Sebastian Redl <sebastian.redl@getdesigned.at> 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 library.
Elaborating on my previous post, here's a quick diagram I drew of the system I envision. http://windmuehlgasse.getdesigned.at/architecture.png
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 framework. 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