Re: [boost] Re: indentation on streams

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2003-06-27 19:19:02

John Torjo on 23 Apr 2003 06:16:20 -0700 (PDT) wrote:

[snip]

 >
 > 2. binding marg_stream to a std::ostream& couples them too much IMHO
 >   (that is, the marg_stream variable is coupled to the other stream).
 >   This actually came to me when I wanted to use col_io together with my
 > thread_safe_log library.
 >
 > The point I'm trying to make (the way I see it) is that I'm not sure you
 > should keep a reference to a std::ostream inside marg_ostream. First 
of all,
 > because the reference might become invalid if the underlying stream is
 > destroyed (which actually happened in my case, since I use
 > temporaries

But doesn't the indent_ostream store an std::ostream& in
m_underlyingOut, and doesn't this mean indent_ostream suffers the same
problem?

 > heavily). Second, the underlying stream and the marg_ostream variable 
might
 > go out-of-sync (formatting information, state, etc.) which could
 > cause

The code at boost/files/col_io/test_ostreambuf_decorator.zip shows an
unbuffered version which, because it's unbuffered, is always in-sync.
However, I don't think this is what you want, but maybe a variation of
it.  I don't think it's what you want because it replaces the
streambuf in the "final" ostream with a linked list of
ostreambuf_decorator_abs's terminated by the "original" ostreambuf of
the ostream.  Hence, the final (actually only) ostream writes to the
ostreambuf_decorator_abs at the head of the list, which does it's
transform and sends the result to the next ostreambuf_decorator_abs or
the final ostreambuf, which was the original ostreambuf in the only
ostream.  However, as you've indicated, this final ostream may
disappear; hence, you want "endpoint" this "pipeline" of
ostreambuf_decorator_abs's to be changeable.  More precisely, you want
the endpoint to be:

                  string_stream_type m_pStreamBuffer;
                
  defined in:

template< class char_type , class traits_type = std::char_traits< 
char_type> >
     class basic_message_handler_log_streambuf;
                
where:

     typedef std::basic_ostringstream< char_type> string_stream_type;
                
as defined in message_handler_log.hpp in your upload:

    http://groups.yahoo.com/group/boost/files/thread_safe_log.zip

And all this means, I think, that if the endpoint of the pipeline is
m_pStreamBuffer instead of the final ostream's streambuf, then you'd
get what you want.  Is that right?