Re: [boost] Alternate Format Mechanism

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-02-11 13:42:20

> >    
> http://www.ece.ucdavis.edu/~kenelson/ofrstream.cc
> > 
> > The general opinion here seems to have been 
> that reuse of the operator
> > << is a bad idea.  Especially because you can 
> end up with something
> > like
> > 
> >    cout << format<char>("%1");
> >    cout << y1; 
> 
> This *works* under the version I submitted.  At 
> least, the following would:
> 
> cout<<format<char>("%1);
> cout<<y1<<endf;

That is a bit better, but it completely excludes
everything but reordering.  Catching things at the
streambuf layer means all of the manipulators have
been applied and the thing is now in string form.
So although it can use arguments multiple times
it certainly won't be able to use them with 2 different
formats.

 
> > % or operator()?  I personally like << but the 
> detractors have won out,
> > and I really don't see operator % as a option.
> 
> The main benefits come from 
> (i) the fact that it can be used over split 
> lines, and can be used with output operations 
> other than << ;
> (ii) the way it deals with manipulators, e.g.
> 
> cout << format<char>("%1 %2") << hex << foo << 
> endi;
> cout << bar << endf;
> 
> This always outputs both arguments with hex (if 
> appropriate for the types, of course), and leaves
> cout in the hex state.

In other words it doesn't deal with manipulators
(cout does).  

> 
> (iii) it behaves well with user-defined types 
> (like format2); 

I believe all of them currently work with user types
because they all proxy to ostream <<

> (iv) it deals with repeated arguments like "%2 %
> 2" at no extra cost beyond the output operation; 
> and

Assuming they must be formatted identically.

> (v) it behaves sensibly when nested (this is more 
> pleasant with the extension I describe below).

Disadvantages:
  - not possible to place any manipulator in
    info in format string.
  - doesn't really handle use with strings, but
     you can do that through

     ostringstream os;
     os << format<char>("%2 %1")<< a >> b <<endf;
     string s=os.str();

   (This seems error prone in that don't streams
    expect their buffer to stay the type they created?)

> 
> I don't really like endi and endf either, and I 
> have altered the code so that endf isn't needed 
> (just endi), and ">>" can be used as a synonym 
> for "<<endi<<", for terseness.  Whilst this isn't 
> ideal, this is the only operator with the correct 
> precedence, and, for cases where you have an 
> iostream (rather than an ostream) (i) endi is 
> still available, and (ii) format, output 
> manipulators and other output operators return 
> ostreams.
> 
> This gives me a syntax like:
> 
> complex<double> a=4,b=5,c=11,d=67;
> cout<< format<char>("%1 %3 %2 %4 ");
> cout<< a >> b >> c >> d >> "foo!" << endl;

This seems dangerous if iostreams are used.

 
> So, >> has a "tab"-like meaning, in that it 
> delimits fields.

 
> I am also concerned about the speed of the other 
> types of format; the only estimate I remember 
> seeing from Samuel Krepp was 200-500%.  The time 
> taken for mine to complete hasn't tested at over 
> 125% of the time for normal stream code in my 
> (admittedly not extensive) testing.

I haven't concerned my self much with speed 
in format3 because any use of there things is
going to involve allocating a bunch of memory on the
side to store the strings.  Thus speed is very
hard to meaure because you depend largely on the
speed measured for vector and string operations
which very by implementation of the STL and what type
of operations we test under.  Thus we would be giving figures in 
apples and oranges terms.

> I have put the updated (and somewhat bug-fixed) 
> version of my format up at 
> http://web.ukonline.co.uk/j.adelman/format/format.
> hpp together with one of my test programs: 
> http://web.ukonline.co.uk/j.adelman/format/test.cp
> p .  On g++ 3.0.3, using -O2 for both tests, the 
> speed ratio is just over 105% for this particular 
> test.

Sounds reasonable. 

--Karl