Re: [boost] Re: formatting manipulator for UTF-8

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-19 11:23:31

----- Original Message -----
From: "Karl Nelson" <kenelson_at_[hidden]>

> I looked over the one in current boost submission and it is really
> very far from mine.  I am not sure I would know even where to
> begin merging them.  Lets just cover the differences.
>
> I choose to make my manipulator as close as I possibly could to
> Unix 98 format specification.  This does mean that many of the
> charactors share identical implementations it feels more consistant
> with generally accepted indicators.

I'll confess: I issued the original challenge which resulted in Rudiger's
contribution. One of my big complaints with printf is that I find the format
specifications impossible to remember, so a goal was to come up with
something much simpler. Another issue is that printf specifiers always
indicate something about the type of the argument to be formatted, which is
completely unneccessary with typesafe C++. I notice you cover that by
allowing %s to format *anything*, not just a string.

> He does add some fancy things
> like centering that mine lacks because those aren't in printf specs.
> However, his format caps the number of arguments to the
> format command at 9 arguments.  Mine code caps out at around 256
> because more than that was kind of pointless.

I'm not sure how compelling it is to be able to format more than 9
arguments. One upside of the boost system is that it is clear exactly which
arguments go with a particular format string.

> His is coded in charT templates.  Mine is currently only 8
> bit form.   Although this is interesting I am
> not sure how applicable it is to a UTF-8 stream.  UTF-8 is exactly
> that 8 bits (with variable length encoding.)   I assume mine could be
> changed but the details of the interactions would likely need to be
> discussed.

For some of us, being able to handle wide characters (unicode) was an
important design criterion.

> Mine is passed on a stream proxy, so it looks like a manipulator.
> His is designed to look like a function.

I think if you review the boost discussions, you'll see that I suggested
this as a way of keeping the format string associated with its arguments as
described above.

> Other manipulators do
> not count as arguments in my.  They do in his.

Yes, I don't love this arrangement. Actually, I don't mind having the
feature, but for ease-of-use I would prefer to see a different form of
manipulators which enclosed the argument to which they applied. For example:

boost::format("%1 != %2", fixed(boost::setprecision(5, 1.9999)), 2.0000);

where fixed and setprecision(5) are being applied only to 1.9999 above.

> His as functions
> has ordering preferences, mine being a stream can not.

I don't understand what you mean by "has ordering preferences".

> This leads to
> big differences in the sample usage.
>
> Here is a quick comparison.
>
> boost current:
>
>   std::cout << format("The Truth is %2%w25%c%1",
>     format("%3%4%1 != %2", 1.9999, 2.000, setprecision(5),fixed),
>             setfill('.'))
>             << '\n';
>
> mine:
>
>    std::cout << format("The Truth is %1$f != %2$f")
>       << setprecision(5) << 1.9999 << 2.000 << endf;

I think one of the biggest problems with Rudiger's examples is that he
overstresses complex capabilities like nested formatting, which makes them
hard to read. AFAICT, your example would not produce equivalent output to
his. I think to get something equivalent to your example, we could write:

  std::cout << format("The Truth is %3%4%1 != %2\n",
    format("%3%4%1 != %2", 1.9999, 2.000, setprecision(5),fixed));

> There would be no way in mine to cap the size of the two arguments
> and center them.  On the other hand standardizing how to
> center "1000.0000 != 10000.0000" if they came out to more than the
> recommended field length seems difficult at best.  Something
> so fancy probably should be left to the user who would
> code to drop precision over accidentally saying
> "1000.0000 != 1000".

I think the boost strategy is to blow off the formatting if the value
representation would be overly compromised. I think this is the same thing
that printf does with field widths. I'm not positive, though.

-Dave