Re: [boost] indentation algorithm for stream objects

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2003-04-03 17:36:35

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.