Re: [boost] Preminary submission: format3

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-01-31 04:55:47

On Thu, 2002-01-31 at 07:33, Karl Nelson wrote:
> > If we extend it to support up to 9 manipulators at a time, we'd use
> > by-value for both g++ and MSVC. (else it makes 1000 different functions
> > template)
> 
> Unfortunately making group for 10 would take 2^10 templates because
> you would need to have group(T&,const T&,...) for 2^10 combinations
> of const T&/T&.  It would be better just to switch to the 
> iomanip implementation I submitted earlier which avoids the whole
> problem.

Yes, I know that T&/T const& overlaods for each of the 10 mnanipulators
make 1000+ different templates. But my point was that we can choose to
pass them by value, and have 10 templates instead of 2^10.
This is more free on the user than requiring him to use only a given set
of provided manipulators, and just as fine. 
(manipulators should not have huge data structures or anything tricky,
so copying is fine)

> No, though I don't know if I should.  That would be attempting
> to graph functionality onto iostream which it simply lacks.  
> I think it would be better to point those out as deficencies of 
> iostream.  

it's true that things would be easier if we could translate all printf
options directly into stream state modifications.
but this is a flag that is surely widely used in current printf calls,
and it affects the output quite a lot ! 
Thus format3 can not claim for printf compatibilty at all.

> Adding functionality to format which isn't in iostream like truncate
> creates the problem that you would need to make a new set of manipulators
> which only work with the format and those have to be seperated out.
> 
>   cout << format("%s" , group(truncate(10),long_string) );
> 
> Thus we get the big problem now how do we get truncate to format
> and not to the ostream.  Ugly!

my idea was to support printf flags only in the format-string.
I think that's what most people will want.

> When I first proposed format class, I hadn't ever intended to
> try to get all of the quirks of printf as it would make the 
> code bloated and cause more interactions that I would want.

it does bloat the code, and eat a magnitude of performance when used.
but I think the users expect this to be implemented.

> Additionally, you can't try to graph them on when using unknown
> types.
> 
> Ie.
> 
>   cout << format("%#0x" , complex<int>(20,21) );
> 
> If you use fill you get 0x in the wrong place, if you add it 
> yourself you will find the imaginary part is misformated.  
> This simply points out how defective iostream is that it
> can't replicate such a simple function as minimum number width.

It's still possible to implement width specification, and for instance I
do support it, even on user-types, by saying that the total output of
the object is padded to the chosen width.
Of course, it's not very efficient, you need to output the object twice
to know where the padding goes, and do some string manipulation by hand.
If the oeprator<< for complex prints 'a+bi', then
cout << format("%#012x" , complex<int>(20,21) );
prints :
0x0016+0x17i

sometimes it may not be what the user wants for a complex hex number
(quite strange an object I think :-)
But at least the width of the total output is respected.

Then again, to satisfy printf users, the easiest would be to rely on
snprintf, converting each of the argument to avoid type-problems, and
trying increasing lengthes of buffer to avoid buffer overflows.
In a hundred lines, everything's done and the class is a perfect
substitute for printf..
So you might be right not to stress printf compatbility after all.

-- 
Samuel