Boost logo

Boost :

From: mfdylan (dylan_at_[hidden])
Date: 2002-01-28 23:31:00

--- In boost_at_y..., James Kanze <kanze_at_g...> wrote:
> The one thing I did have to do at a customer
> site was recognize ostream manipulators, and use them to terminate
> format, and shift back to outputting to the ostream. The rule
> horrible and unorthagonal, but works well in practice, where people
> write things like:
> logfile << GB_Format( "..." ) << x << y << std::endl ;
> (and want the flush).

I did some more experimenting with this. It seems that trying to
support operator<< is actually a lot more complex than I originally
thought, especically if you want to support something like the above.
Re your comments about operator% having the "wrong" precedence, it's
exactly this fact that makes operator% perfect, because

std::cout << format("...") % x % y << std::endl;

is parsed as

std::cout << (format("...") % x % y) << std::endl;

which makes it extremely simple to implement (only one "format" class
is needed, as opposed to a bunch of strange classes that I couldn't
even think of reasonable names for!). So I'm now firmly in favour
of '%'.

The main issue that concerns me is that the Unix-98 printf
specification is just way too complex. For a start, I really don't
see the point in having to specify the type when the compiler knows
it anyway (you mentioned something about literal '0' - how often
would you really use this, and what's wrong with 0.0 anyway?). On
top of that, after using it god knows how many years, I still have to
look it up every time I want to specify a number to be displayed with
a certain width or precision (or understand the difference!). I
think before making any sort of decision on this someone needs to
gather together as many existing "format string" examples from large
projects that have been internationalised and look at what
functionality is really needed, then attempt to come up with
something that is trivial to use for the most common cases (ie no
width/precision specifications), tolerably easy for the more common
uses of width/precision (in my experience this means they are
determined at run-time, not hardcoded!), and manageable with a bit of
help from documentation for the most obscure cases. In my book the
printf rules don't fit this pattern. Coming up with something better
is not really "reinventing the wheel", its realising that horse &
cart wheels aren't appropriate for modern cars :o)


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