Re: [boost] Re: Thoughts on Format

From: James Kanze (kanze_at_[hidden])
Date: 2002-02-09 10:38:19

Karl Nelson <kenelson_at_[hidden]> writes:

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

I think it better to keep currency and time out of this for the moment.
Both require significantly more than any of the current proposals offer.
At the least, we would need a new manipulator, saying to use currency
format, or a new type specifier.  Date and time are even worse.

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

I'll second that.  When I implemented my GB_Format, printf compatibility
was part of the specifications.  As a result, I found that I had to
overload on every single built-in type, as well as for strings, and
write special code to implement the features not present in ostream.
Whether those features are important or not depends on what you are
doing, but I've used precision with %s a couple of times, and found it
rather pratical.  (You can, of course, get the same effect with ostream
and string by outputting a substr() of the string.)

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