Re: [boost] Re: Thoughts on Format

From: Karl Nelson (kenelson_at_[hidden])
Date: 2002-01-31 14:33:10

> --- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> > On 1/31/02 9:53 AM, "bill_kempf" <williamkempf_at_h...> wrote:
> > 
> > > I've never encountered a situation where a translator would need 
> to specify
> > > any formatting information, and so including it in the string 
> makes the
> > > translator's job more difficult.
> > 
> > OK that makes sense.
> > 
> > I would strive for a design where formatting that might need 
> localization
> > goes into the string. It seems nice to be able to keep other 
> formatting
> > details that will not need localization out of the string.
> > 
> > I guess you're just saying that the change that formatting will need
> > localization is close to zero.
> 
> At least in my experience.  I'm not steadfast against including 
> syntax to allow it in the string, but I doubt I'd ever use it and 
> think it's important that the design not require it.  

Then does format3 address that?  

Positional only...

   cout << format("How may %1% can you buy for $%2%?", s1, 
                    group(fixed,precision(2),s2) );

And printf...

   cout << format("How may %s can you buy for $%.2f?", s1,s2);

Note the above is a good example of something which the manipulators
may be translated totally differently based on the currency.  Thus 
having them in one format string is good.  Arguably you can do this
by having currency format and using it, but format has no problem with that.

  cout << format("How may %1% can you buy for %2%?", s1, currency(s2));

where currency can be
inline string currency(float f) { return format("$.2f",f).to_string(); }

> type specifiers is a huge mistake, and including other formatting 
> specifications should be considered carefully.  In most cases the 
> only thing I find missing is positional parameters.  Otherwise 
> iostreams outshine printf and all it's warts in every possible way 
> (well, performance is another issue, but hopefully implementers will 
> find a way to fix this as well).

I don't think iostream does outshine given that many things
that printf does like %#08x aren't even possible in iostream.
After all the code complexity in the format libraries is coming
from "iostream doesn't do what printf does easily", not some
feature creep.

--Karl