Re: [boost] Preliminary submission: format3 version 0.1

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-02-01 11:36:55

> From:	Karl Nelson [SMTP:kenelson_at_[hidden]]
> > 
> > Does cout << format("%#010x" , complex<int>(20,21) ); mean
> >   A) the user wants all integers output to be show base with
> >      12 charactors zero padded.    0x00000016+0x00000017i
> >   B) The total width should be 10 with showbase and zero padding?
> >      0x16+0x17i
> 
> I would definitely expect B.  Otherwise, the width has relatively little
> control over the output; any user-defined type could wreak havoc on
> formatting.

The problem is you just interpreted "width" to mean "maximum width".
But in this context it means "minumum width".  As it does in iostream
as well.  In fact, iostream would completely ignore width for
the above specifier.

==========================================================
#include <iostream>
#include <iomanip>
#include <complex>
using namespace std;
int main()
{
  for (int i=1;i<1000000;i*=10)
  {
    cout << setw(5) << i << "  ";
    cout << setw(5) << complex<int>(i) << endl;
  }
}

    1  (1,0)
   10  (10,0)
  100  (100,0)
 1000  (1000,0)
10000  (10000,0)
100000  (100000,0)
===========================================================

Thus either A or B would have been better.

I should also point out that matlab printf does A, not B.
As a simple point, "%10s" would mean min 10 spaces for a string
"%.10s" would mean no more than 10 spaces for the string.  You could
apply that by extension to decimals, but then of course it makes no
sense where floats are concerned.  

This is a big lump in printf formating (which we should not replicate)
which is the width field means generate no less than.  According to that
rule I would guess output A.  It generated no less than 10 chars for
each int conversion.

Second point, is that unlike fortran C++ does not have a cap limit
when you hit the maximum.  Ie.  should format("%.4d" , 12345) print
1234, 2345, or ####?

> > Should formating of int and float be in iostream instead 
> > Ie.
> >    os.float_format("##.####");
> >    os.int_format("0x0######",hex);
> > rather than the simple state machine?
> 
> This is the direction that we should pursue: replacing/augmenting IOStreams
> to provide the facilities we need rather than trying to graft on a hack.
> IOW, create boost::basic_ostream<> as a drop-in replacement for (ultimately
> in an updated standard, ideally) std::basic_ostream<>.  Doing that means we
> can design the interactions at the lowest level rather than trying to graft
> them on after the fact in an unsatisfactory way.
> 
> To answer the question specifically, I would appreciate the ability to
> specify formatting with such format pictures.

I agree.  Making a format which can do something more than iostream 
can do makes no sense as format should just be a tool for 
compact representations and reordering.

--Karl