Date: 2002-02-11 14:36:01
Quoting Karl Nelson <kenelson_at_[hidden]>:
> > >
> > >
> > > The general opinion here seems to have been
> > that reuse of the operator
> > > << is a bad idea. Especially because you
> > end up with something
> > > like
> > >
> > > cout << format<char>("%1");
> > > cout << y1;
> > This *works* under the version I submitted.
> > 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
> streambuf layer means all of the manipulators
> been applied and the thing is now in string
> So although it can use arguments multiple times
> it certainly won't be able to use them with 2
Of course not. I didn't see at first that this
was the purpose of these statements.
> > > % or operator()? I personally like << but
> > detractors have won out,
> > > and I really don't see operator % as a
> > 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
> > appropriate for the types, of course), and
> > 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
> 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
> > (iv) it deals with repeated arguments like "%
> > 2" at no extra cost beyond the output
> > and
> Assuming they must be formatted identically.
> > (v) it behaves sensibly when nested (this is
> > pleasant with the extension I describe below).
> - 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-
> - doesn't really handle use with strings, but
> you can do that through
> ostringstream os;
> os << format<char>("%2 %1")<< a >> b
> string s=os.str();
> (This seems error prone in that don't streams
> expect their buffer to stay the type they
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
> > have altered the code so that endf isn't
> > (just endi), and ">>" can be used as a
> > for "<<endi<<", for terseness. Whilst this
> > ideal, this is the only operator with the
> > 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
> > 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.
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
and be suprised when bar and baz don't get output.
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"
> > So, >> has a "tab"-like meaning, in that it
> > delimits fields.
> > I am also concerned about the speed of the
> > types of format; the only estimate I remember
> > seeing from Samuel Krepp was 200-500%. The
> > taken for mine to complete hasn't tested at
> > 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
> 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
> 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
> > I have put the updated (and somewhat bug-
> > version of my format up at
> > hpp together with one of my test programs:
> > p . On g++ 3.0.3, using -O2 for both tests,
> > speed ratio is just over 105% for this
> > test.
> Sounds reasonable.
This mail sent through UK Online webmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk