From: "Jonathan Turkanis" <technews@kangaroologic.com>
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:ch86rj$rqb$1@sea.gmane.org...
3. The example
filtering_streambuf<input> in; in.push(alphabetic_input_filter()); in.push(cin);
mentions something about the source comming last. Maybe it would be more explicit to say
in.push_filter(alphabetic_input_filter()); in.push_source(cin);
assuming there is a stakc of both types. If there is only one source, then maybe in.attach_source( cin );
There is just one stack. It consists of zero or more filters with an optional resource at the end. See the diagrams here: http://tinyurl.com/5v2ak.
Resources represent the ultimate data source/sink, while filters modify data as it passes through. So it wouldn't make sense to have a resource in the middle or a filter at the end.
One of the original motivations for introducing the i/o categories (they turned out to be useful for a lot of other things) was to avoid having separate functions push_filter and push_resource. I consider it a major simplification of the interface.
I agree with Thorsten that some means of ensuring that parts aren't assembled in the wrong order would be helpful. Whether that means separate functions, or detection of the type of object being pushed, it seems like preventing misuse should be a bigger priority than "a major simplification of the interface." There are plenty of places where one can misuse existing libraries, including the Standard Library, so perhaps requiring that protection from this library is misguided. So, here's another approach: perhaps you could create a set of overloaded make_* functions that take a varying number of filter arguments followed by an optional (via overloading) resource argument. Then, those functions can ensure that if there is a resource, it is push()'d last. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;