Re: [boost] Alternate Format Mechanism

From: j.adelman_at_[hidden]
Date: 2002-02-11 14:36:01

Quoting Karl Nelson <kenelson_at_[hidden]>:

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

Of course not.  I didn't see at first that this 
was the purpose of these statements.

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

Of course.

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

Sorry, this comparison is with another interface 
I considered and rejected.  But your example from 
format3 used type specifiers; I assume these are 
optional? 

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

I guess it replaces the bare format, and none of 
pformat; in this, it doesn't duplicate existing 
functionality.  I'm not convinced it is 
beneficial for this information to be dealt with 
by the translators -- it seems likely to cause 
errors which the application can't deal with, as 
is being argued in other threads about exception-
throwing.

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

All I can say to that is: If they do, they are 
severely broken -- basic_iostream doesn't have 
virtual functions and hiding virtual functions is 
flawed; and relying on the return type of rdbuf() 
being something other than the declared return 
type requires a (dynamic) cast, whose error 
condition should be checked.  If this isn't the 
way in which rdbuf() is supposed to be used, why 
isn't it protected?

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

Yes.  I wish there was another operator with the 
same precedence.  As I say, the only good thing 
is that the << or >> or manipulator nearest the 
stream object controls the input/output semantics.
Thus,

fstream file("somefile");
file<<format<char>("%1 %3 %2 %4 ");
file<< 5 >> 6 >> 7 >> 8 >> endl;

is all output, not an erroroneous attempt to 
input into literals.  Of course, one could still 
easily do

file<<format<char>("%1 %2")<<foo;
file>>bar>>baz;

and be suprised when bar and baz don't get output.
Both

file<<format<char>("%1 %2")<<foo;
file>>hex<<bar>>endl;

file<<format<char>("%1 %2")<<foo;
file>>bar>>"\n";

and variations thereon naturally cause errors.  
The only way in which it gives maximal surprise 
is when you have an 
iostream>>var1>>var2>>...>>varn; statement with 
no literals and no attempts to do un"tabbed" 
output.

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

Yeah.  I just thought that my version was going 
to be slow (as I mentioned at first), and only 
timed it, because I wanted to improve the logic 
to reduce memory allocations.  I decided not to 
bother when I saw that it wasn't as slow as I 
expected.  I believe however that Samuel (with 
whose figures I was comparing) does use g++ 
3.0.*, so those figures should be okay to 
compare.  

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

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