RE: [boost] Re: Thoughts on Format

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-29 09:58:32

From:	Brey, Edward D [SMTP:EdwardDBrey_at_[hidden]]
> 
> > From: Samuel Krempp [mailto:krempp_at_[hidden]]
> > 
> One thing to keep in mind is that printf does not have to deal with static
> manipulators, whereas format does.  This means that format needs more
> options.  For example, a static manipulator may be set to left align.  It
> would be useful to allow a placeholder to override this.  With printf's
> current use of '+' and '-', there is no easy way.  However, a syntax like
> [1:>] makes it pretty clear that the first argument should be right
aligned.

The directionality of < and > will work well for left and right alignment.
What about centering?  printf() and IOStreams don't provide for that, but
it's a common formatting task that I'd rather the library got right once and
for all.

> Besides adding functionality, there is room for general readability
> improvement.  IMHO, %08.2f doesn't provide much of a visual clue to help
> remind me that the zeros will prepend the number to fill up the 8
> characters.  Something that helped emphasize that the zeros would be used
to
> create a right alignment would be better, e.g. [1:8.2/0>].

I like that, but I suggest altering that slightly: [1:8.2>0].  The idea is
that ">" is already useful as a delimiter, so there's no need for both ">"
and "/".

> > width and precision settings are ok with printf syntax.
> > run-time width specification is done like "%*g", i.e. you use '*'
> > instead of the width, and this means it will take the corresponding
> > argument as the field width.
> > In positional context, it becomes : "%1$*2$g", meaning the first
> > argument is converted as a general float number, with width given in
> > argument number 2.
> > (BTW, this mechanism is not supported by Boost.Format at the time. it
> > should, in the near future..)
> 
> Do we need to put the width specifier in the placeholder at all?  Why not
> just put the width in a local manipulator?  We need to include the width
> among the arguments anyway.  So long as a translator would never want to
> bind the width to a different placeholder, there would be no functionality
> lost.  I can't think of a case where the placeholder that the width
applies
> to isn't constant.

I'll posit a situation that may not match reality, but, then again, maybe it
does:  when translating the format, it may be that the format for the
alternate language requires a different width.  For example, when formatting
a number with separators, don't some languages put separators after two
digits in some places and three in others?  Translating among such a
language and one that always puts separators after three digits would change
the width in some circumstances.

Assuming it is necessary to parameterize the width, how about this syntax:

    [1:[2]>0]

By nesting the [n] specifier, we get to reuse the symbology.  I don't
propose that full nesting be supported.  That is, references to a parameter
for the width/precision would not support formatting information.

Note that if parameter 2 is an integer, then the call is specifying width
only.  If the parameter is floating point, then it is specifying width and
precision.

Now, let me introduce an entirely new concept into the discussion: spring
tabs.  Many years ago, Borland released a word processor called Sprint.  I
loved that app.  It was completely scriptable in a C-like language which
made extending it fun and powerful.  Nevertheless, that app used a tab
concept which I call "spring tabs."  (I can't remember if that was their
term or not.)  Spring tabs make left, center, right, alignment and other
horizontal formatting highly intuitive.

A spring tab works, like its name implies: like a spring, pushing in two
directions equally.  In the examples that follow, "@" will represent a
spring tab:

    1. Right
        "@text"

    2. Center
        "@text@"

    3. Left and right
        "text_at_text"

    4. Left, center, and right
        "text_at_text@text"

    5. 1/3 and 2/3
        "@text_at_text@"

    6. 3/4
        "@@@text@"

If we could incorporate spring tabs into this formatting class, it would be
a generalized, powerful, yet easy to use, improvement.  We'd have to decide
what character represents a spring tab, but I think it would be highly
useful.  I have implemented the logic for spring tabs, so this isn't an
abstract concept that would require significant effort.

What do you think?

Rob
Susquehanna International Group, LLP
http://www.sig.com