wchar_t values

[Randall Atkinson]

In article <661 at taumet.com> steve at taumet.com (Stephen Clamage) writes:

>This is the kind of attitude which annoys those in the world whose native
>language is not English.  I am not in that category, but in working on
>the ANSI C++ committee I have been made aware of the sensibilities of
>the European members.
>
>One member's name contains an umlaut (two horizontal dots above a vowel).
>He asked us to imagine how it feels NEVER to be able to see your name
>spelled correctly in any computer correspondence.  (I can't even provide
>the example here.)
>
>Another member asked how we would feel if, for example, the letters
>'l' and 'r' would always be considered equivalent, and the letter 'f'
>was forbidden.
>
>[Anothel membel asked how we wourd eer i, ol exampre, the rettels
>'r' and 'l' wourd arways be consideled equivarent, and the rettel ''
>was olbidden.]

This is a problem with character sets and has been FULLY RESOLVED
by the ISO with the creation of the ISO 8859/* family of 8-bit
character set standards.  ISO 8859/1 supports all national languages
used in Western Europe including umlauts and accents and tildes
and everything.  The problem is with the terminal and OS 
implementations not with any programming language.  There is NO
REASON to force the language to try to resolve a terminal/OS issue.

>So let's turn Peter's question around:  Why can't the Americans use
>a preprocessor to convert ASCII source into some international
>character set before compiling?  (I don't advocate this, but it seems
>like an equally fair question.)

ASCII is a proper subset of ISO 8859/1 and to force US ASCII to be
modified as suggested above before compiling will mean that ALL
EUROPEAN users who are migrating to the ISO 8859 character set
standards will also have to preprocess FOREVER.  By contrast,
the ISO 646 7-bit variant code standards are DEPRECATED by the
arrival of the ISO 8859 family and so those folks using ISO 646
would be using preprocessing temporarily and eventually would
be able to stop using it as their equipment supported ISO 8859
so the preprocessing requirement would be TEMPORARY and TRANSITIONAL
rather than PERMANENT.

Note that even Keld ackowldeges that ISO 646 is "fading" in favor
of ISO 8859/* and hence the problem is also going away.

Randall Atkinson