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

[Paolo Carlini]

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.

Of course, there is *plenty* wrong!! But it's the law!! You either 
follow the
law, change the law, or... end up in jail!! Are you anarchist?? ;)

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

Or perhaps tried but simply provided the corresponding traits, as we all
know is in general necessary and consistently with basic_string.

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

Perhaps.

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

I can't, on the spot. But here I have to ask you to read again my very first
sentences above: one thing is working together on what the next
standard will be (it would be an honor for me: I learned already so much
from you, indeed, and Benjamin and Nathan, to mention two other
active participants), another thing is deciding to not follow, for the
gcc that's *now* delivered, a lot of paragraphs in the standard for the
sake of PODs without traits, against all of our previous releases, without
a single PR and with just a DR in the Open status (and a negative
statement). Honestly, that seems foolish to me.

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

Agreed ;)

Paolo.