Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk