I disagree. The following (almost) line by line translation of your example to marg_ostream:
As I said, I don't know the details of the implementation, so that was a speculation based on how I presumed it was implemented.
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.
The problem lies in what to do when reading in data from an external source like a file. In that instance, you have to manually scan the file for '\n' characters and indent then.
This is a problem with my design, one solution to which would be to provide a special method for string output that performs the indenting on '\n' characters and the default << operator for strings and characters does not do this.
I have made several improvements to the original code, including:
[1] added a security check for indentor::endIndent() to prevent m_indent.level dropping below 0
[2] added the ability for indentor::indent() to output a newline character
[3] indent() is now implemented using width() and fill() functions from OutputFileType, restoring their values afterwards - thanks to Larry Evans for the suggestion
[4] added char/wchar_t support by inheriting the character type from OutputFileType
-rhd- mailto:[EMAIL PROTECTED]
_________________________________________________________________
Worried what your kids see online? Protect them better with MSN 8 http://join.msn.com/?page=features/parental&pgmarket=en-gb&XAPID=186&DI=1059
indentor.zip
Description: Zip compressed data
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
