Re: [boost] Re: Thoughts on Format

From: James Kanze (kanze_at_[hidden])
Date: 2002-01-30 17:56:11

"mfdylan" <dylan_at_[hidden]> writes:

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

I don't know.  I added the feature for a customer once, and I don't
remember it being a particular problem.  Just a specialization of the
operator<<( GB_Format&, T const& ) template.

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

The problem is that 

    format( "..." )  % x * y % z ;

is parsed wrong.  Generally, this should result in a compiler error, but
I would be very surprised if we can get away with not having format
implicitly convert to std::string, which means that:

    format( "..." ) % x + y ;

will NOT be a compile time error if x and y are strings.

IMHO, the best solution is just to forget about the operator (and the
implicit conversions), but try selling that.

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

What strange classes.  My implementation of format uses a number of
helper classes.  I could probably have avoided some of them if member
templates had been available when I initially designed the code, but
making manipulators switch back to ostream didn't add any classes.

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

So is C++.  It works.  People use it.  It's not really any more
complicated than the basic printf, and that seems to enjoy a lot of
popular support, regardless of what you or I think of it.  (Anyone for
"print using" ?)

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

It's true that the printf uses the format specifier for two things, the
type, and how to format it.  And obviously, a C++ implementation doesn't
need the first.  But is there an easier way than %f and %e to say that
you want fixed or exponential format?

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

That's interesting.  I don't, but then, I've implemented a C standard
library, so one could assume I knew the rules better than most.  But
I've never seen any problems at any of my customer sites, either.
Generally, not everyone knows all of the option flags, but the all know
how to specify width, precision, left or right justification, and
leading zeros; most also know how to specify the base for integers.

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

The problem is that most of this is proprietary, and cannot be taken out
of the customer site.  (What I can say is that the user of width or
precision determined at run time has been rare.  Probably rarer than it
should be, but in some cases, it depended on the locale, so it was
natural to put it into the text files.)

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

But then we should throw the concept out completely, and invent
something really new:-).

-- 
James Kanze                                mailto:kanze_at_[hidden]
Conseils en informatique orientée objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. [phone]