[Patch] Fix the narrow/widen problem in money_get::do_get

[Martin Sebor]

Paolo Carlini wrote:

...
> Really?!? Therefore you are telling me that all those implementations
> completely ignore 22.2.6.1.2, p4 and the note?!?

This was actually discussed in the connext of num_get but it
stands to reason that implementations that call narrow() there
will also call narrow() from money_get. I surveyed about 6
implementations myself (3 versions of ours, STLport, and a couple
of Dinkumware's), and Howard Hinnant chimed in saying that
Metrowerks also calls narrow(). So yes, I am saying that all
these implementations ignore the requirement to widen(). Ours
does so deliberately in order to allow the facets to be
instantiated on user-defined charT's. Plus, our narrow() is
quite efficient in the common case (char, and wchar_t values
between 0 and 256), so we're not concerned about the potential
performance issue Nathan was referring to in his post (calling
do_narrow() for each character).

> 
...
> 
> Wait a minute: if I understand well what you saying about the
> "missing traits", the same issue would affect num_get and 22.2.2.1.2, p8
> and our reading of it, because of course for num_get::do_get we
> are following the very same approach, using traits::find and
> widening in advance. Clearly strictly following the standard.

Yes, both money_get and num_get are affected.

> 
> If that is the case, I (we) will definitely go ahead with my
> money_get::do_get patch, if only for consistency with the
> rest of our implementation.

That's too bad. Yours will be the only implementation to behave
that way. It's probably not going to cause a huge portability
issue for anyone, but it will be an incompatibility nonetheless.
What's more serious is that by following this obscure and, IMHO
arbitrary requirement your implementation might violate a much
more important and useful requirement, namely that it be possible
to instantiate those facets on user-defined character types.

Btw., here's the issue on the "traits problem" in num_get that
I mentioned earlier:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#427

Note that I disagree with text in the note added in Kona,
specifically that

   "changing numeric facets to use narrowing instead of widening:
   it wouldn't fix the general problem, it would be a drastic
   reversal of a deliberate change, and it would probably have
   unfortunate performance implications.)"

It's not at all clear that the change is drastic (especially
given existing practice and given my comments on the semantics
of narrow() in my response to Nathan earlier in this thread),
and it would clearly not have unfortunate performance
implications (our implementation does quite well).

Martin