Boost logo

Boost :

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


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

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
hpp together with one of my test programs:
p . On g++ 3.0.3, using -O2 for both tests, the
speed ratio is just over 105% for this particular

> --Karl


James Adelman

This mail sent through UK Online webmail

Boost list run by bdawes at, gregod at, cpdaniel at, john at