Boost logo

Boost :

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:
> [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:
> 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


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
>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at