Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-08 22:41:17

"Jonathan Graehl" <jonathan_at_[hidden]> wrote in message
> >
> >
> > struct alphabetic_input_filter : public input_filter {
> > template<typename Source>
> > int get(Source& src)
> > {
> > character c;
> > while ((c = boost::io::get(src)).good() && !isalpha(c))
> > ;
> > return c;
> > }
> > };
> >
> >
> >
> (boost::io::)character is just a type that wraps an int with a good() test?

int_type or optional<char> would be good enough for that. The important point is
that there are two separate 'not good' states -- one means end-of-sequence and
the other means no data is currently available.

> >Here, eof and fail values are passed on to the caller unchanged. If you want
> >send an eof or fail notification explicitly, you'd write return eof() or
> >fail().
> >
> >Now the big question: is the above formulation too convoluted to teach to an
> >average user who is interested only in plain, blocking i/o?
> >
> >
> >
> That seems fine. For such a user, this is just boilerplate code pasted
> from documentation examples.

What worries me is that users already know about char, int and EOF. To use
character properly probably requires more than just copying from examples.

> If you really care to make filters written by naive users via a simple
> blocking interface applicable to more advanced nonblocking scenarios,
> you can design a generic adapter that turns a blocking filter into a
> nonblocking one. That is, it would wrap both the upstream and
> downstream, I imagine with a dynamically growing buffer that will accept
> any single output the naive user wants to produce, but then flagging
> when its downstream consumer doesn't accept the entire amount, and
> returning the EAGAIN equivalent to its upstream instead of calling the
> user's naive blocking method. This strategy would require a close
> notification since the buffered unaccepted stuff would be left alone
> until the next write attempt (unless you want to spawn a thread to spin
> attempting to empty the buffer).

I hadn't thought of that. I'd much rather teach people how to write correct
filters, so they can be used with maximum efficiency. There's also no good way
to turn a blocking input filter into a non-blocking one -- unless you consider
that every blocking input filter is sort of a degenerate non-blocking filter.

> About the close() or open() methods for a filter that wants to write
> some prelude or coda (e.g. gzip): aren't these only necessary because
> you can't guarantee that the constructors and destructors for the filter
> stack are called in the proper order?

No -- filters should be reusable. Here's an example from a reply I wrote to Rob
Stewart (it turned out not to be relevant to that discussion, but maybe it'll be
relevant here ;-).

"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
> struct zlib_ostream : filtering_ostream {
> zlib_ostream() { push(zlib_compressor()); }
> template<typename Source>
> zlib_ostream(const Source& src )
> {
> push(zlib_compressor());
> open(src);
> }
> template<typename Source>
> void open(const Source& src )
> {
> BOOST_STATIC_ASSERT(is_resource<src>::value);
> push(src);
> }
> bool is_open() const { return is_complete(); }
> template<typename Source>
> void close(const Source& src )
> {
> assert(is_open());
> pop();
> }
> };

int main()
    using namespace boost::io;
    zlib_ostream out;"hello_world"));
    out << "hello world!";
    out << "goodbye world!";

Only one zlib_compressor is constructed, but it is used several times.

> It would be nice if source -> A
> -> B -> sink could guarantee that B is (finally) constructed after sink,
> and then A is constructed after having been linked to B. That is,
> aren't the filters passed by const reference and only copy constructed
> once into the filter stack? I guess the part about ensuring that A is
> linked to B before the user constructor code might be accomplished by
> inheritance (superclass constructors always complete before subclass
> constructor executes, and the reverse for destructors?) I'm not sure if
> this is too clever, or can't be made to work portably, though.

Actually, I can run the destructors in any order I want, since I'm using
boost::optional<Filter> to avoid requiring that filters and resources be default
constructible. So I can just do filter_ = none;

> I don't think a second, simpler interface would be that much of a win;
> the complexity of having two interfaces or types of filters would add as
> much confusion as it simplifies the blocking case.

I've lost you here. Which is the 'second, simpler interface' which you don't
think is a good idea?

Best Regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at