"Larry Evans" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
I'll soon upload a commented an simplified version of marg_ostreambuf and maybe a templatized version to parameterize the addedState. I may rename it too to decorated_ostreambuf or something similar.
I think there is no need for marg_ostream at all. Why reinvent a bicycle if
The only reason is to avoid passing 2 objects, i.e. the ostream& and the
accompanying indent_decorator. Of course, you can get the indent_decorator from the ostream with rdbuf and a cast; however, this
was demonstrated by the marg_ostreambuf.cpp in the test_marg_ostreambuf.zip which I uploaded yesterday.
one can use original std::basic_ostream<>. And it would be great if marg_ostreambuf were parameterized by char and traits types like original std::basic_streambuf<>.
Agreed.
Here is the code for decorator.
This looks pretty much the same as marg_ostreambuf in the test_marg_ostreambuf.zip, except the indent_decorator is not
derived from ostreambuf and uses marg_ostreambuf as a member
variable. Also, it's not unbuffered. Making it unbuffered
allowed simplification of marg_ostreambuf, as you can see by
comparing the marg_ostreambuf's in col_io.zip and
test_marg_ostreambuf.zip. Also, I was thinking that
using the you might want to string together the fwd_ostreambuf's
much like a unix pipe. For example, you could provide a
lineno_ostreambuf which numbers each line followed by the
marg_ostreambuf which indents you code.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
