Re: [boost] indentation algorithm for stream objects

[Larry Evans]

Reece Dunn wrote:
Larry Evans wrote:

[snip]
There are two possible ways I see at simplifying your marg_ostream:
[1] 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).
[2] 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.beginIndent();
  out.indent() << "Indented" << '\n';
out.endIndent();
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:
[snip]
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
to marg_ostream:
    ; marg_ostream mout(cout)
    ; unsigned i=0
    ; mout << "This is a test" <<i++<< endl
    ; ++mout
    ; mout << "Indented" << endl
    ; --mout
    ; mout << "End of test" << endl
produces:

This is a test0
  Indented
End of test
[snip]
Another indentor advantage is there's no need
to define operator<< for all the primitive types as was done in
marg_ostream.


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