RE: [boost] Review : format2, yet another 'printf class'

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-06-30 17:57:00

> I like this one. However, it actually should be:
>
> format(" $1 $2 $3", make_tuple(x, y, z));
>
> and this is already less attractive, at least for me. Still, I think it's a
> move in the right direction :).

it's also in the direction of more complexity in the techniques used..

Right now, my mind is made on this : I settle on python's operator%,
 used like
format(" .... ") %x %y %z

It will take a vote with a majority against %  out of at least 30 boost
people to make me change my mind  ;-)

> My main problem with '%' is that it's not an idiomatic C++, at least not yet

yes, but in a line like
cout << format(" %1 %2 %3") %x %y %z << "bla bla";
(or,
logMessage(format("Error: %1 with x=%2") %msg %x);

it should not be too hard to guess that % cant be the arithmetic modulus.
Anyway, everybody should at least play a few hours  with python in their
life, beacause it really is nice.
And thus, everybody should be used to python's usage of %.
And thus format's usage of operator% should look perfectly natural to
everybody, The case is closed..  ;-)

>  Also, using of '$' in format specification, but '%' when providing
> arguments seems inconsistent.

it's true that I would prefer to have only '%' in the format string.
currently it is used by printf-type format specifications, whose shortest
form is
%s   (not positionnal)
and
%N$ or %N%  when positionnal. (N=number from 1 to .. 2^30.. )

BTW the very-short, 2-letters,
%N  is not as sound as the previous forms.
When N can grow above 9, there is no way to know when N stops and when the
rest of the format string begins, except testing for 'isdigit'.
so you can *not* write digits right after an argument.
Or you need a special 'empty string' directive, say "% " , to act as
separator when you need one :
format("%1% 45") % "aa"  == aa45

which is an ugly exception.

the more rigid, 3-letters, %N% syntax does not have any exception..
That's because there is an end-marker, '%'.
In printf syntax, there is a set of letters that act as end markers, and
that are required. it's the  type indicators, d x X e E f F g G ..  The
syntax can freely define usage of all others chars between the begin and
end markers (so adding % as an end-marker allow to easily support %3%,
which is precisely what I did)

Whereas, supporting %N implies getting rid of %Ns %Nd %Nx, ..
even "%N ". (space is a printf flag..)
thus to leave printf compatibility aside.

I had brought '$' in, to distinguish short directives
vs printf's % directives, so as to allow both.

An alternative is to have 2 format constructors,
format and pformat (or whatever, meaning 'printf format')
% and $ uses being exchanged between one and another.
So people needing printf compatible format are happy, using pformat,
and people liking short notation are happy too.

Then, we can provide a few other 'short notation' directives,
similar to what was available with previous format class.

or just declare that "$xxxx" should be treated the same way as "%xxxxx"
is treated in printf parsing.

(since having both $___ and %____ in a format string isnt pretty, we can
instead define %p_____ to be treated as a printf directive when in
non-printf mode, at last getting rid of $ .. )

In conclusion :

Since printf compatibility is already implemented, and  printf syntax
is quite robust and extensible actually, and has no bad impact on the class
-the only thing it requires is the appropriate parsing code in the
"process(string s)" function, which is not too complicated-
my feeling is that format *should* provide this "printf compatibility".

the pformat solution is a good solution to provide it.

When called in format, the priority is given to *short* directives,
%1 %2..
but more complex printf ones are accessible via %p_____ .

Sounds all right ?

-- 
Sam