Hi,

I came a little late - sorry about that.

Anyway, I have a more thorough implementation of nullstream,
since there are more details that could be taken into considerance.

I've attached the code - if anyone is interested, I can comment on them
a little.

The idea is that you might need to sometimes pass nullstream to a function
taking an ostream& reference.

At this point you have two options:
- ignoreoutput (which silently ignores output)
- failbit - which is much faster than ignoreoutput, since it sets the
  std::ios::failbit on the stream. Internally, when something is written to
the stream,
  first a check is performed to see if the stream is in good state. If it's
not, the
  function ends right there.


Best,
John

----- Original Message -----
From: "Jeff Garland" <jeff@[...].com> 
To: "Boost mailing list" <boost@[...].org> 
Sent: Thursday, September 25, 2003 2:24 PM
Subject: Re: [boost] streams - basic_nullbuf


>  On Thu, 25 Sep 2003 Lars Gullik Bjønnes wrote
> 
>  > Jeff Garland wrote:
>  > > My approach was a bit different in that I didn't bother with the
buffer at
>  > > all, but created the ostream interface directly in hope that the
> 
>  >But if you are going to compile anyway, then you could use other
>  >methods as well (pre-processor).
> 
>  Yes, but macros are evil and impact code readability.  I just really hate
lots
>  of code like:
> 
>    TRACE("I'm here" << foo << std::endl);
> 
>  The all caps thing is really bothersome to me.  And of course there is the
>  loss of ability to set have a tracing version and a non-tracing version in
one
>   compilation unit.
> 
>  > How will this behave for user defined types?
> 
>  Same because of omitted detail below...
> 
>  > Do I have to add a operator<< for both ostream and null_ostream?
> 
>  No...
> 
>  template<class T>
>  null_ostream&
>  operator<<(null_ostream& os, const T&)
>  {
>    return os;
>  }
> 
>  I'm not saying my idea was fully baked -- there may be some fatal flaw I
>  haven't worked out.  Just wanted to point out other potential approaches
and
>  requirements while expressing support for getting something like this in
boost.
> 
>  Jeff
> 
> 
>  _______________________________________________
>  Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
> 
>