Re: [boost] Alternate Format Mechanism

From: j.adelman_at_[hidden]
Date: 2002-02-11 13:01:54

Quoting Karl Nelson <kenelson_at_[hidden]>:

> > It's manipulator-like; it can work for user-
defined types.  Currently,
> 
> > though, it is expensive. It needs a seperator 
between units, because
> in 
> > general there is no way to know what is and 
is not a manipulator.  
> 
> I have a library to define manipulators in a 
unified framework
> which solves that part of the proble.  There 
should be enough
> interest to have it submitted.
> 
> > Pretty 
> > much safe.  It's only meant to be a proof of 
concept at present.  Any
> 
> > interest?
> 
> That syntax is what I already submitted eons 
ago.  See 
> 
>    
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;

> The real question here is what value did you 
get from 
> specifying each argument using an operator over 
a function?
> Compare yours/format2/format3...
> 
>    cout << format<char>("%1 %2") << name << 
endi << count << endi <<
> endf;
> 
> verses (format2)
>   
>    cout << format("%1 %2") % name % count;
> 
> verses (format3)
> 
>    cout << format("%1$s %2$s")(name)(count); 
> 
> How much clarity was gained from using an 
operator << verses operator
> % 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.

(iii) it behaves well with user-defined types 
(like format2); 
(iv) it deals with repeated arguments like "%2 %
2" at no extra cost beyond the output operation; 
and
(v) it behaves sensibly when nested (this is more 
pleasant with the extension I describe below).

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;

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

> --Karl

Cheers,

James Adelman

-------------------------------------------------
This mail sent through UK Online webmail