[boost] Re: Review of Daryle Walker's "More IO" library beginstoday, August 21, 2004.

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-28 14:36:54

"Daryle Walker" <darylew_at_[hidden]> wrote in message
news:BD55A2D6.E82D%darylew_at_hotmail.com...
> On 8/24/04 2:18 AM, "Jonathan Turkanis" <technews_at_[hidden]> wrote:
>
> [SNIP]
> > I think Daryle's pointer streams and null streams are useful, and may
> > vote for their acceptance, but believe they would be better
> > implemented as Sources and Sinks. Most of your ideas below also fit
> > easily into this framework.
> >
> > For example, using my library, a null_buf and null_ostream can be
> > defined as follows:
> >
> >     struct null_sink : boost::io::sink {
> >         void write(char*, std::streamsize) { }
> >     };
> >     typedef boost::io::streambuf_facade<null_sink> null_buf;
> >     typedef boost::io::stream_facade<null_sink> null_ostream;
> >
> > Pointer streams can be defined like so:
> >
> >     typedef boost::io::streambuf_facade<boost::io::array_resource>
> >             pointerbuf;
> >     typedef boost::io::stream_facade<boost::io::array_resource>
> >             pointerstream;
> [TRUNCATE the more complicated ideas]
>
> But why go through all the trouble to forcing an idea through a framework,
> which is built on top of the Standard I/O framework, when the idea is simple
> enough to go through the Standard framework directly?

The components, such as null_sink and value_source, are actually *easier* to
write than the corresponding stream buffers.
They can also be reused in cases where streams and stream buffers are not
necessarily the best abstraction.

So I don't see this as a case of forcing them into a framework. As sources and
sinks they express their core functionality concisely; as stream buffers, the
are forced into the 'basic_streambuf framework' with its pecular interface
(underflow, uflow overflow, xsgetn, etc, eback, pbase, ....)

Jonathan