Re: [boost] Re: Thoughts on Format

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-01-29 11:34:54

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

#4 can't be optional as you need an end tag.  Printf is well designed
in that the start flag % must have an end tag.  However it is 
problematic in that the string almost must be parsed backwards as the
meaning of precision and width vary.  

I don't want to reinvent printf though as as has been pointed out 
dozens of times printf is the standard that outside coding firms
are most likely to use.  Thus conformation is good. 

Of course if I had to do it again I would want to make it more clear
like.
   %{ [argument$ type] | [type] [: [flags ... ] }

%{x:w30p.>}  hex - width 30, pad char ., aligned right
%{8.3f:w20}  float with 8 char and 3 decimal.  width 20.
%{}          unspecifed argument (next in sequence)
%{2}         second argument

or some such.  However, even that can't be nearly as terse as
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.

You should not have to specify the order of the argument by default.
It would induce errors to do so.  After all when the programmer writes
it they will write.  "My dogs name is %s"  Reordering is a low
level feature not used often excepted in translation.  

People keep putting to high of emphasis on the reordering which 
really is only rarely used.   In printf format is a optional arguement
used in secondary strings only.  How often is a coder going to 
really write "[2] has [1] balls" rather than just reversing the
arguments in the code?

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

I argee.  If you are trying to do variable manipulation 
use a manipulator.  

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

Well I will submit my revised formating tool shortly.  Hopefully
it will help the debate by giving an alternative.  I am however,
going to go with the flow and submit it with syntax

  cout << format( fstring, a1, a2, a3 ) << endl;

--Karl