Re: [boost] Boost.Format syntax

From: James Kanze (kanze_at_[hidden])
Date: 2002-02-16 10:59:04

"Brey, Edward D" <EdwardDBrey_at_[hidden]> writes:

|>  > From: James Kanze [mailto:kanze_at_[hidden]]

|>  > |>  I agree with the desire for printf compatibility.  But trying
|>  > |>  to find a nice syntax that allows it just isn't easy.  For
|>  > |>  example, using the "%1$s" use mentioned above, what happens if
|>  > |>  the value substituted is a string that the context string will
|>  > |>  make plural.  Its not pretty: format("%1$s %2$ss") [3]
|>  > |>  ["banana"].

|>  > But it doesn't occur in practice.  You can't just add an s to make
|>  > a word plural.

|>  You can given a suitable precondition. :-) Yes, I agree, this
|>  example isn't the best (although I've seen it, both with the
|>  precondition and with '(s)'.  The larger point is that there is a
|>  significant minority of times when this happens.  Usually when
|>  adding tabs, newlines, percentages, and the like.  They all are a
|>  bit easier to read when a fully enclosed placeholder.  Short of
|>  that, string concatenation helps, but it isn't quite as nice as an
|>  enclose placeholder would be.

I'm not really against something for grouping.  In addition to printf
format, if you wish.  I do think it would help legibility; if used
systematically in an application, it would sure be easier to explain to
the translator (everything in the {...} which follows a %).

|>  > |>  What harm is there in completely separating the printf syntax
|>  > |>  into a different class?  Is there really any desire to use
|>  > |>  (pseudo-)printf syntax and a modern syntax within the same
|>  > |>  format object?

|>  > I've yet to see a suggestion which effectively separates
|>  > formatting and parameter ordering.  I'd like to.  I agree that
|>  > they are two different issues completely.  But I don't see how to
|>  > separate them effectively.

|>  I don't think that it is as simple as syntax ordering vs. not.
|>  Syntax ordering isn't the only advantage that comes from not
|>  requiring printf compatibility.

|>  > I can't resist citing CAy Horstmann's home page here:

|>  >     The March of Progress

|>  >     C 
|>  >           printf("%10.2f", x); 
|>  >     C++ 
|>  >           cout << setw(10) << setprecision(2) << showpoint << x; 
|>  >     Java 
|>  > 
|>  >           java.text.NumberFormat formatter 
|>  >              = java.text.NumberFormat.getNumberInstance();
|>  >           formatter.setMinimumFractionDigits(2);
|>  >           formatter.setMaximumFractionDigits(2);
|>  >           String s = formatter.format(x);
|>  >           for (int i = s.length(); i < 10; i++)
|>  >              System.out.print(' ');
|>  >           System.out.print(s);

|>  > Although he forgot the fixed in C++, not to mention putting the
|>  > stream back into it's original state.

|>  > Viewed this way, maybe the printf syntax isn't so bad afterall.

|>  Good example.  At least Java uses fully descriptive names.  With
|>  C++, you get not only verbosity, but you are still stuck with
|>  cryptic naming.  Why is the code setting the unicode character width
|>  to 10 bits? :-)

Why isn't the function called "width"?  And why "setw", but
"setprecision", and "fixed"?  There seems to be a singular lack of
coherence.

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