Re: [boost] formatter

From: Samuel Krempp (krempp_at_[hidden])
Date: 2001-12-16 22:38:20

 On Thu, 2001-12-13 at 12:30, David Abrahams wrote: 

> Similar work has come up for discussion on this list numerous times. 
> The most recent time, it even came with code from Samuel Krempp
> <krempp_at_[hidden]>. Unfortunately, after generating much
> discussion and interest, the work was never formally reviewed for
> acceptance. Clearly, there would be lots of interest in such a thing.

I had not touched the code and doc in the vault since July. I had not
insisted on getting a formal review at that time, mainly because I
expected trouble with the code under gcc2.95 and other 'old' compilers. 
(and indeed it does not compile)
Now the release 0.2 of gcc3 has been released, 
and, in general, issues caused by compilers that are miles away from the
standard  are living their last hours. (at least, I hope so) 

Jens Maurer reported success in compiling the code with KCC and comeau,
but not Intel 5.0.1 beta.
gcc2.95 also fails to compile, but gcc-3.0 has no problem with it

On the two last days, I finalized modifications on the code, worked the
docs, and provided simpler samples of code (the previous samples
concentrated on complex usages) 
I uploaded all this in the vault.

I think it's almost ready for formal review, there might just still be a
few not very pretty lines of code here and there that I should take the
time to make prettier, but as far as I know everything is fine.

If you take the time to glance at the code (or even just the doc) and
have any suggestion on points that need polishing before requesting a
formal review, I would appreciate it a lot.
In absence of such feedback, I don't really grasp what I have to polish
before the formal review and I'd plan to ask for formal review in a
matter of weeks..

IMO, The only remaining issue is that some printf directives are not
emulated fully in the current approach. 
(The design of my class is simple : translate the printf directives into
stream options, dump the variable to an internal stream, then apply a
few modifications to the converted string to implement what the stream
did not do)

Currently the last step can not know whether the string is the
conversion of an int, a float, a string or whatever. 
So options like '0' or ' ', which have no effect on non-numeric
variables in printf, do have an effect on any type of variable with my
class. 

This could be handled, eg by using type_traits::is_integral, is_float,
and have the formatting code call a function specialised according to
those  traits. 

But then, there would still be a dilemna for user-defined types. 
suppose we define a RationalNumber class (as defined in
example/sample_userType.cc in the archive on th evault)
then : 
RationalNumber r( 16, 9);  // r= 16/9. 
pformat("%+d") % r; 

should it yield "+16/9" (current), 
or consider that RationalNumber is not one of the types (float/int/ ..)
for which '+' should  have an effect, and thus yield 
"16/9"  ? 

strict obediance to printf specifications would imply the second choice,
but that's because it was never designed with user-defined types in
mind.
I personnally prefer treating all types equally, to allow user-defined
types to be affected by special options just like built-in arithmetic
types. Anyway, a user should not specify a "+" flag on a string, just
because he knows it has no effect with printf.

The other option is to redesign the class to handle a bigger part of the
formatting inside the class (instead of giving everything to a stream)
eg, James Kanze's code, mentionned as 'alternative' in the doc, chose
this approach.
Of course, it makes the code much bigger and more complex.

Well, I tried to find all printf directives that don't translate well
into a stream context, and write a list of all such directives leading
to possible differences of result between printf and format.
I wrote a paragraph for this list in the doc, it's called 'differences
of behaviour vs printf'

This list is probably not complete yet  (looking at the deep details of
all possible mixes of printf options is quite a boring task and I've
never had the courage of examining all possible conjonctions) but it
already gives an estimate of what kind of contexts can lead to imperfect
emulation of printf (not many, and they're all rare and unnatural, so
I'm satisfied)

ah, BTW, performance is surprisinly not too bad considering all the
dynamic allocations in the many stringstreams and strings used.
I did some tests, with help from Jens Maurer, they showed a factor 5.8
between pformat and snprintf, for the same task. 
It becomes 3.5 when you deduce the time it takes to parse the format
string (my code for this can surely be optimised)

-- 
Sam