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?