Re: formatter

From: vonosan (alnsn_at_[hidden])
Date: 2001-12-17 02:40:20

--- In boost_at_y..., Samuel Krempp <krempp_at_c...> wrote:

> 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

I compiled formatter class on VC6 SP3 and gdd-3.0 both with and 
without STLport-4.5

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

I started with printf compatibility too but I found that it is not
so important and it complicates the implementation. So I chose 1-1
mapping between ostream flags and formatter flags.

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

Let the implementor of RationalNumber choose. I'm sure he or
she will implement operator<< with ostream flags in mind. 

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

I have factor 2-5 compared with ostingstream (it depends on compiler
and STL library implementation). I didn't optimized my code yet.

---------
Alexander