[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?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
