Re: Some details on the named locale problem

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Jan 28, 2002 at 04:50:36PM -0800, Ulrich Drepper wrote:
> Nathan Myers <ncm-nospam@cantrip.org> writes:
> 
> > In the C++ implementation it suffices to take the first character
> > from the string found, and if that's NUL, then so be it.
> 
> And this alone is broken.  There is no requirement is the locale
> definition (POSIX and ISO C) that the thousand separator isn't a
> multibyte character.  This is explicitly accounted for in the ISO C
> locale model by using a string.  

I already noted the above in my last posting.

> It's not possible for the C++
> interface to represent this information.

Of course anyone who has bothered to understand the C++ locale already
knows that it doesn't deal in multibyte characters.  Anyone who needs 
an external multibyte representation is assumed to be using a wide 
stream, where the separator character is a wide character.

For that case, the numpunct_byname<wchar_t> code should convert a 
multibyte character found in the locale file into a single wide character, 
and return that.

Differences between C++ and C are not bugs.  In general, differences
indicate bugs in C that we deliberately chose not to propagate into C++.
In some cases C bugs leaked into C++ anyway because even idiots' votes 
count.

A good example is std::copy, which returns a pointer one past the last 
value written, rather than to the first value written, as in memcpy.  
std::copy can be more efficient because after the loop has run, you 
have the return value in hand.  memcpy must explicitly preserve the 
initial destination pointer, or regenerate it by subtraction, to return 
it.  This design error was propagated into the char_traits<>::copy member,
(in direct violation of committee rules designed to protect against 
ill-considered changes) at the last meeting before the draft was sent 
to the ISO for approval.

Another good example was the late requirement that for std::string s,
the value of s[s.length()] was defined to be NUL rather than left
undefined, despite that the effect of assigning that element is undefined.  
As a result, many string operations must be careful to plug in a NUL
there (otherwise unnecessarily); it is impossible to share storage
with substrings; and for types that have no natural NUL value you need 
to invent one just to make a string out of them.  (It probably took the
C fans all of five minutes to break C++ strings while I was out of the
room.)

Nathan Myers
ncm at cantrip dot org