Boost logo

Boost :

Subject: Re: [boost] [iostreams] in vault
From: dherring_at_[hidden]
Date: 2010-01-14 11:07:23

On Wed, 13 Jan 2010, Larry Evans wrote:
> On 01/13/10 11:17, dherring_at_[hidden] wrote:
>> On Tue, 12 Jan 2010, Larry Evans wrote:
>>> On 01/12/10 11:29, dherring_at_[hidden] wrote:
>>>> I wrote a similar utility, but made different tradeoffs. The basic
>>>> usage looks like
>>>> Indentation nl; // takes optional max depth and depth/level params
>>>> Indentation::Indent in(nl); // could have used a reference notation
>>>> Indentation::Outdent out(nl);
>>>> std::ostream os;
>>>> os << nl "class x
>>>> << nl << '{' << in /* or */
>>>> << nl << "int x;"
>>>> << nl << "int y;" << out
>>>> << nl << "};"

And assuming an initial depth of 0, this outputs
class x
   int x;
   int y;

>>>> - distinguishes between indenting and normal newlines
>>> I'm not sure what this means. Does it mean that to indent
>>> a line, you have to use nl, as shown in this snippet of the code
>>> you posted:
>>>> << nl << "int x;"
>>> If so, then I'm not sure that's an advantage. Could you
>>> please elaborate on what you mean?
>> Yes. In my work, this is a great advantage. People don't like text
>> with trailing whitespaces, but they want blank lines for visual separation.
> Doesn't:
> os<<nl<<"\n"
> produce trailing whitespace whose length is the current indentation
> level which is stored somewhere in nl. Hmm... What's the return
> type from os<<nl. I'm guessing it must be typeof(nl)& because
> otherwise, how would the change in indentation be communicated from
> the <<out at the end of the output line:
> << nl << "int y;" << out
> Could you clarify how out changes the indentation? Does it modify
> the nl that occurs at the beginning?

In my implementation, [pseudocode]
operator<<(\n) is an ordinary newline
operator<<(nl) inserts a newline followed by the current indentation
operator<<( increments the depth of nl but produces no output
operator<<(nl.out) decrements the depth of nl but produces no output

Since all indentation operations occur in operator<<(), they all happen in
the expected sequential order.

>> I could see an argument for having \n indent and nl not; it may make it
>> easier to compose indentation with output functions that do not
>> understand it. However, my experience has been that an indenting
>> newlines semantically belong before the line text while a traditional \n
>> appears after the text. This creates a mismatch; a general indentation
>> tool should probably have a (scoped) mechanism for switching behaviors.
>> Example: (pseudo C++)
> However, I don't see where the indentation for the vector comes
> from because there's no calls to nl in the operator<< specializtion
> for vector<int>. Am I missing something?

I was suggesting that an implementation could hook into \n for its
indentation. Mine doesn't because the semantics usually aren't right
anyway. Indenting newlines work best in a prefix position; normal
newlines usually appear postfix.

However, a general indentation utility should probably allow \n to behave
as nl.

os << nl << "foo" << << nl;
nl.wrap(os) << "bar\n"; // to reuse printers ignorant of indentation
os << "baz\nquux";

would output

>>>> - possible to maintain several indentation systems
>>> Could you describe when this would be an advantage?
>> This is rarely useful, but there are times when indentation
>> differentiates between classes of output line. This is naturally
>> represented by having one indentation object per class.
> Couldn't this be handled by defining operator<< for each class?

Here "classes of output" was not meant in the C++ usage of "class" but
rather "category". So you can't have a custom operator<<; indentation
might be specified by a value in the object, by the identity of the
object, by the identity of the containing object, ...

Example you might see in a foreign language course:
         How are you?
Good, and you?
         Fine, thank you.

Which could be written as
os << TomNL << "Tom"
    << MaryNL << "Mary"
    << TomNL << "Hi!"
    << MaryNL << "How are you?"


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