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

[Martin Sebor]

Paolo Carlini wrote:

> Martin Sebor wrote:
> 
>> If implementions simply chose to disregard a reasonable requirement
>> in the standard and provided an alternative reasonable behavior,
>> the document is irrelevant and existing practice is what matters.
> 
> 
> Probably, tomorrow you will re-read this and will admit that it doesn't
> make any sense, especially for a member of the Working Group.

I doubt it. The main purpose of standards, and IMO their greatest
value is in codifying existing practice or its intersection. Just
because I am a member of the WG doesn't mean that I take what's in
the standard as sacred and ignore real life. Clearly, there's
plenty wrong with the document.

> 
...
> I want only to point out that the concerned behavior (involving widening
> in advance and comparing via traits::find) was already in 3.2 and nobody
> filed a PR about that in the last year and half or so.
> 
> Humbly, taking into account the size of the gcc users base, this point 
> should
> be not disregarded, when talking about "existing practice".

Most likely because no one relies on the many obscure requirements
in C++ locale and no one has tried to instantiate your num_get on
a POD. If we're willing to acknowledge the former the easiest way
to fix the standard is to just leave it unspecified how the
comparison is done.

 > That PR is in the Open status and the only official position so far,
 > that which you are mentioning, is **clearly** against your point of
 > view.

Yes, unfortunately it is. But I think I gave pretty good reasons
why the arguments against the proposed resolution in the Note are
baseless and why it may not even matter whether widen() or narrow()
is called. Can you refute them?

But I didn't write to challenge the importance of your or any
other implementation, to question your design choices, or to
argue about who's right and who's wrong. I was mainly responding
to Nathan's suggestion that an implementation technique advantageous
to one implementation should be used to dictate the design decisions
by the C++ committee, possibly forcing other implementations to make
changes that put them at a disadvantage or that might prevent them
from conforming. I certainly wouldn't want to put the libstdc++
developers in that position, so I would welcome and will seek
a solution that will allow existing implementations to conform
while at the same time allowing your implementation to be
efficient.

Martin