This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Fix the narrow/widen problem in money_get::do_get
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.