RE: [boost] Re: Thoughts on Format

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-29 09:30:53

> From: Samuel Krempp [mailto:krempp_at_[hidden]]
> 
> I'm not sure we can come up with a new, simpler, syntax than that of
> printf. 
> at this level of conciseness, printf's syntax is still quite clear.
> 1. (optional) flags (alignment, padding, ..)
> 2. (optional) width
> 3. (optional) '.' + precision
> 4. type-character

I like the general breakdown of printf, as you've summarized above (except,
of course, that (4.) should be optional).  However, when you look at the
details within each category, I think it is possible to do better than
printf.

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.

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

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

> It would be interesting to collect such a database of 
> 'real-world format
> string samples', and try to design the formatting syntax of the new
> millenium.
> (One of the possibke challenges I came to notice, is extending the
> formatting options to apply to any user-type printable 
> object, and thus
> handle nested outputs.. the current syntax is not suited for this
> context)

This would indeed be a very useful exercise, with a worthy goal.  I like how
you put it: a "formatting syntax of the new millennium".