Re: Boost.Format review comments

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-21 15:53:35

Question of operator% vs operator[]:

Beman recently pointed out an old post about a third option, which was to
formal arguments.  I think it makes sense to investiage this path completely
before going down the operator overload comparison, although, I found
Samuel's detailed discussion of the topic quite enlightening.  Are there any
advantages that either of the overloading styles have over formal arguments?
The only one I can think of is consistency with the specification string (as
Doug pointed out).  With the overloads you could have:

  cout << format("writing %3,  x=%1 : %2-th try") % 40.23 % 50 % "toto";
or 
  cout << format("writing [3],  x=[1] : [2]-th try") [40.23] [50] ["toto"];

Note that the [1] style in the specification string is a new idea (inspired
by Doug's comment about operator%).  It is nice in that it cleanly solves
the problem of dealing with digits after the position specifyer.  (I don't
want to hear any comments about extra keystrokes for typing brackets except
from people who have unshifted percent signs on their keyboards ;-).
Seriously, though, I would tend to think that the encapsulation of the
formal argument method provides more benefit than consistency between
specification and argument syntax.

There is another downside to formal arguments, which is that there is no
syntax for differentiating manipulators from arguments.  However, I suspect
most of the formatting will be part of the specification string, anyway
(after all, we're using format() for a reason), and so this shouldn't factor
significantly into making the decision.

Question of str()/to_string()/operator string():

The first question here is whether a conversion operator is acceptable, or
alternatively, if format can multiply inherit from string and stringstream.
We know how to solve the problems caused by weak operator binding.  However,
Sumuel mentioned, "Still, without implicit conversion, some typos would be
caught at compile-time instead of producing run-time errors."  Could you
elaborate on this?

Question of being subtly different from printf:

Beman raised the point of the syntax between format and printf being
different, but too close.  The major differences are (1) the name "format"
vs. "printf", and the placeholders "%1" vs "%u".  This seems like a pretty
substantial difference to me.  One could go further by changing the
placeholder to "[1]", but this doesn't seem necessary for differentiation
purposes.

Direct responses:

[Samuel]
>I already said I'd provide a way to choose what errors throw exceptions,
>so I've finally implemented it, with inspiration from the iostream
>'exceptions' functions.
>
>using namespace boost::format;
>format fmter(" %1 %2 ");
>fmter.exceptions( all_bits ^ (not_enough_args_bit | too_much_args_bit));
>cout << fmter [100] [200] [300] [400] ;
>// Okay, extra arguments quietly ignored.

This seems quite reasonable.  "too_few_arguments_bit" and
"too_many_arguments_bit" would be better names.

>I could add a parameter in the basic_format constructors, to pass
>the exception mask at construction time, but in practical use,
>it would not be as clean as a user wrapper function anyway.

Agreed.  The issue of object reuse also complicate the formal argument
approach.  Perhaps there would need to be N constructors and N operator()s.

>the non-legacy formatting code is very minimalistic..
>It relies on the printf directives for left/right/centered alignment,
padding,
>and all other fancy formatting options.
>I felt that designing a new syntax for precise formatting would complicate
the
>whole thing even more, so for now the new syntax is just "%1", "%2", etc..

OK.  Since the printf formatting rules are OK, it is reasonable to reuse
them.  It would be different if they were very difficult to use.

>> what if I'm not interested in printf compatibility, but want to center
text?
>
>As I said, the 'short-style' notation can't be used to specify formatting
>options,
>My decision was to provide 2 possible notations : 
>- one basic, very concise notation to adress simple needs
>- printf notation for printf compatibility OR for any precise
>formatting need.
>(the new formatting features are provided in this style of notation,
>not the short one)

OK.  This wasn't clear to me from your documentation.

>> Credits:
>> - "Karl Nelson formatting" ->
>>  "Karl Nelson's formatting" ->
>
>[Fixed] 
>on the same note, I'm not sure what to do with the first name, but I
>think the whole sentence should be : 
>"ideas from both Rüdiger Loos' and Karl Nelson's formatting classes" 
>Is this right ? 

Good question.  I've often wondered this myself.  I couldn't find an
authoritative answer after a bit of looking.  I suspect that either is
acceptable.  Even the opinion of how to handle appostriphies after names
ending in "s" seems to vary a bit.

>> str2int(): Why use the long if/else block rather than n += s[i] - '0'?
>
>[Unsure] 
>because I'm not sure it's guaranteed to work in all cases. 
>(all platforms, and wchar_t as well as char) 
>Is it ? 

Good question.  This goes into i18n beyond what I know.  Do you need to use
the traits parameter to convert '0' to be of the same type as s[i]?  Can you
assume that all 10 digits in a character set are sequential?  It seems
reasonable, since you are assuming base 10?  The assumption might be able to
help your optimizer a good deal.