Re: Thoughts on Format

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 
the
> format, and shift back to outputting to the ostream.  The rule 
sounds
> 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)

Dylan