From: Larry Evans (jcampbell3_at_[hidden])
Date: 2003-04-03 17:36:35
Reece Dunn wrote:
> Larry Evans wrote:
> There are two possible ways I see at simplifying your marg_ostream:
>  Overload string operations only since you only really need to
> intercept '\n' characters - this appears to be the simpler of the two
> solutions (as there is no real need to overload for integer types, only
> strings and characters).
>  Write a stream buffer that intercepts the '\n' characters - this
> seems overly complicated and a little overkill.
Agreed. I had to work at it IIRC.
> NOTE: I have not yet looked at the code for marg_ostream so I cannot
> give any more detailed comments on it at the moment.
Thanks. I'll think some more about it, when I get some time.
> One of the reasons I chose not to have the '\n' character trigger the
> code to perform the indentation is that you could have code like:
> out.indent() << "This is a test" << '\n';
> out.indent() << "Indented" << '\n';
> out.indent() << "End of test" << '\n';
> It makes sense to have the new lines at the end of the output. If,
> however, the '\n' character triggered the indentation, you would need
> something like:
> which is less intuitive and can lead to mistakes if you are not careful.
> The reason for this is that the indentation will be done at the wrong
> time and lead to incorrect alignment of the string "Indented".
I disagree. The following (almost) line by line translation of your example
; marg_ostream mout(cout)
; unsigned i=0
; mout << "This is a test" <<i++<< endl
; mout << "Indented" << endl
; mout << "End of test" << endl
This is a test0
End of test
>> Another indentor advantage is there's no need
>> to define operator<< for all the primitive types as was done in
> That is due to the aim at keeping indentor's design as simple as
> possible, while giving it as much flexability as possible. Redefining
> the operator<< would have severly complicated the design.
That's why I like your way; however, in the back of my mind,
there's a feeling I started out that way (this was done years ago)
and for some reason, after running some tests, found it better to
do it this other way. I think the problem was I didn't always
know when the beginning-of-line occured; hence, I needed the
marg_ostream to keep track of this. I can't remember specifics
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk