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

[Nathan Myers]

On Thu, Feb 26, 2004 at 12:35:56PM -0700, Martin Sebor wrote:
> Paolo Carlini wrote:
> 
> >Martin Sebor wrote:
> >
> >>As I said on the reflector the last time we discussed the issue,
> >>an efficient but mainly simpler implementation is possible (and
> >>exists -- ours) that calls narrow(), not widen(). 

I don't know the details of this implementation.  Does it assume that
only one wide-character value maps to each digit?  I.e., suppose I
supply a string 1X3Y, where X and Y narrow to 2 and 4, respectively.
Does your optimization work sensibly?  Does it extract 1, or 1234,
or do something strange?  The standard as published specifies,
deliberately, that it extract 1.

> >>Additionally,
> >>as I also pointed out in the past, the requirement Paolo refers
> >>to above is unimplementable for any specialization of these
> >>facets other than on char and wchar_t, and implementations that
> >>follow it only violate the standard in another area.
> >
> >Honestly, I don't follow. It seems to me pretty clear that the standard
> >talks about widen, not about narrow (see note 237!?!)
> 
> That's true. But existing practice suggests that the requirement
> is bogus -- no implementation that I know of has ever followed it.

Refusal by implementers to conform is not prima facie an argument that 
the requirement is bogus.  In all scrupulousness you need to show that 
the requirement is also harmful.

I didn't mean to accuse Martin or Howard of seeking to interfere with
optimization of competing library implementations.  

> >and we don't
> >really care what an user of the library want to do for types != char,
> >wchar_t (Table 51).
> 
> You should care. Look at table 52. A conforming implementation
> is required to make it possible to instantiate money_get, money_put,
> num_get, and num_put on any POD character type.
> 
> >Moreover, I don't see DRs involving 22.2.6.1.2.
> 
> If there isn't one it's only because no one has filed it yet.
> 
> The "missing traits" problem has been discussed a bunch of
> times. The only thing facets need traits for is character
> comparison. Unless we add a traits parameter to the facets
> that need it, the only two ways to solve the problem are
> to require that charT's be equality-comparable (no such
> requirement currently exists) or to have xxx_get<charT>::
> do_get() call ctype<charT>::narrow() and compare the narrowed
> down versions of the charT's. Actually, I suggested a third
> approach -- have the facets look for a traits_type typedef
> in the charT type and use it if it exists, and otherwise use
> std::char_traits<char>. This approach didn't meet with much
> enthusiasm, but neither was there a clear preference for
> either of the other two.

The much simpler approach, and which I thought was the consensus,
was that many of the char_traits members -- particularly move,
copy, and comparison -- were leftovers from a failed experiment.
I.e. early drafts didn't require charT to be a POD.  Since in the
published standard it must be a POD, those members serve no real
purpose.  (IIRC the need for them to be PODs was realized at the 
Stockholm meeting.)  Therefore, implementations should be encouraged 
to use ordinary assignment and operator==, and let the unused traits 
members be deprecated.  I don't see any value in combing through the
sources finding places where the traits could be used; instead, I'd
like to see the standard changed to acknowledge that the simpler code
necessarily has the same effect.

Nathan Myers
ncm-nospam@cantrip.org