Re: [boost] Re: Thoughts on Format

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-01-29 05:53:32

On Tue, 2002-01-29 at 05:31, mfdylan wrote:
> Re your comments about operator% having the "wrong" precedence, it's 
> exactly this fact that makes operator% perfect, because
> 
> std::cout << format("...") % x % y << std::endl;
> 
> is parsed as 
> 
> std::cout << (format("...") % x % y) << std::endl;

Indeed that's why I chose '%',
I looked at the table of operators precedence for possible operators
listed above '<<'. (among which '%' seemed like the best candidate)

> which makes it extremely simple to implement (only one "format" class 
> is needed, as opposed to a bunch of strange classes that I couldn't 
> even think of reasonable names for!).  So I'm now firmly in favour 
> of '%'.  

Personnally I think of them as 'format_stream_proxy', or something like
that, since it encapsulates both the stream and the format data.

One additional drawback with those classes, is it's then very tricky to
let users manipulate format objects (feed one argument at a time, etc..)
because those proxy hold smart pointers.

E.g, in karl nelson's class, the proxy object returned by
( cout << format(s) ) << ....
is non-copyable.

I had tried to state those arguments for '%' in the documentation, but I
had difficulties explaining the point :
"precedence of % also is higher than that of <<. so technically things
are straight-forward".
not very enlightening.. :-(

I'm rewriting this with more details, because this choice is probably
the most exposed to critics, and all the reasons behind '%' should be
described clearly.

> The main issue that concerns me is that the Unix-98 printf 
> specification is just way too complex.  For a start, I really don't 
> see the point in having to specify the type when the compiler knows 
> it anyway (you mentioned something about literal '0' - how often 

me neither. I'd like those to be optional.
(e.g., when you want to have heaxadecimal output, you'd use x. but not
'd' for regular int output.)
In the printf syntax, the type-flag is crucial, for detecting the end of
the directive, but If the new syntax is %{stuff} for any non-trivial
directive, we don't need it.

> top of that, after using it god knows how many years, I still have to 
> look it up every time I want to specify a number to be displayed with 
> a certain width or precision (or understand the difference!).  I 

well, now that I implemented the parsing of printf format-strings, I
think I'll remember the meanings of all the flags for the rest of my
life. It even seems natural to me now.. 8-}

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

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

> think before making any sort of decision on this someone needs to 
> gather together as many existing "format string" examples from large 
> projects that have been internationalised and look at what 
> functionality is really needed, then attempt to come up with 
> something that is trivial to use for the most common cases (ie no 
> width/precision specifications), tolerably easy for the more common 
> uses of width/precision (in my experience this means they are 
> determined at run-time, not hardcoded!), and manageable with a bit of 

Right now, I don't have precise ideas on how to design a simpler syntax
for that. (except taking away the type character when not needed..)
The previous Boost.format by Rüdiger Loos, in the vault -folder 2000,
had a basic set of syntax rules, that parsed "%w12%r%3" as : "width 12,
right aligned, argument number 3"
but I doubt it could compete with printf's syntax.

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)

I'd gladly take part in this effort, but not launch it on my own.
It goes well beyond boost.format, which is for most part independant of
the chosen syntax.

-- 
Samuel