From: Rob Stewart (stewart_at_[hidden])
Date: 2004-09-03 14:05:19
From: "Jonathan Turkanis" <technews_at_[hidden]>
> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> > 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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk