Re: [boost] nullstream (was: Re: regression test feature requests)

From: Ed Brey (brey_at_[hidden])
Date: 2001-01-26 12:32:40

From: "Daryle Walker" <darylew_at_[hidden]>
> > Sounds like a call for a boost library (or library portion).  Seems
like
> > an easy one, since the base stream buffer class does nothing by
default.
> [TRUNCATE over-simplified versions of null-stream(buf) classes]
>
> I already have something like this in the Boost vault, in the "more_io"
> package.  I don't bother making external objects of those classes,
though.
> (BTW, you have to override the output functionality; the default rejects
any
> output, you need it to take any output without complaint [or real
> processing].)

I had taken a brief look at more_io and apparently missed the null stream
capability.  I had in my head that it was for filtering only always had an
input and output.  Yahoo is being obnoxious right, and so I can't get to
the vault at the moment for a closer look.  Looking at the standard, I see
your point on having to override to return success.  My test programs
worked fine, but I wasn't looking at the stream state.

I would like to raise the issue about providing an external object for
this functionality.  It would seem like a null stream is an object for
which there would never be a reason to instantiate more than once (at
least within a single thread).  In that case, it is convenient to have a
predefined object.  Having a single global object can be better since time
is not spent creating and destroying it multiple times, and there is never
more than one allocated in memory at once.  OTOH, having a single global
object can be worse, since memory for it is always allocated, even when
zero are in use, and if the program never uses it at all, the startup and
exit time are wasted.  (However, if the program never _references_ it at
all, it won't get linked in, (right?).)

More often than not, I would expect that the first hand to win out, and
the existence of cin, cout, and cerr lends credence to that.  Along those
lines, the names, nin, nout, and ninout may be appropriate, depending on
how cryptic one is willing to get to maintain std-stream-style names
(although, personally, I'd say no, since a name like nin would show up
rarely in code whereas cin may show up frequently.)

Somewhat on the topic, I'm interested in opinions on adding a debugging
output stream (dout seems like a good name for the external object) that
would send its output to whatever is appropriate for the platform.  I'd be
willing to provide a Windows implementation which sends the stream to the
debugger.  The debugger does what it wants to with it (MSVC sends it to a
dockable output window).  Do most other development environments have some
sort of special debugging output location that can be mapped into.