Fehringer Franz writes:
> setlocale(LC_ALL, "german");
> printf("%s\n", setlocale(LC_ALL, 0));
> printf("%x\n", '=E4');
> It prints
> (btw. why is hex(a umlaut) =3D=3D ffffffc4?)
a) Short-term: Your code works in practice. As long as you use an
editor, compiler and OS that agree on these things.
'=E4' as a character in WinLatin-1 encoding is usually expressed as 0xC4
or 196. But in the C language, '=E4' is usually thought of as a
"(signed) char" (-60). This is passed as a "(signed) int" to the
varargs function printf(). Inside printf() "(signed) int" -60 is
interpreted as an "unsigned int" (%x) and so you get the above. For
pretty-printing you want instead:
printf("%x\n", (unsigned char) '=E4');
You can also use the GCC option -funsigned-char to force all plain
"char" entities to be interpreted as "unsigned char". But that is a
compiler-specific option, so you get non-portable code if you rely on
b) Long-term: Note the three dependencies above (there are probably
even more). IMO it is much more portable to cut out the dependency on
editor and compiler, treat C/C++ as ASCII-only and use '\xC4' instead.
Or, even better, use external data files in known encodings (or even
Windows resources). External data files also let you design
localization into other languages much better.
> The following C++ program using std::locale does not work, it gives
> locale::facet::_S_create_c_locale name not valid
[Note that I haven't looked into this issue specifically myself
before. So all that I am saying is based on general knowledge of
the system and a quick look at some relevant web pages. I haven't
looked at the source and I have not conducted any tests.]
The C locale framework is provided by Microsoft's C runtime library.
The C++ locale framework OTOH is provided by a separate C++ library,
Libstdc++ probably uses the standard POSIX names and Unix-style
infrastructure. This may not work at all on Windows, because you
usually wouldn't have that infrastructure. Check the code, it is part
of the regular GCC sources.
> Does this work with current snapshots or can this be enabled with
> future ones?
If somebody puts in the necessary work, I guess.
Given the extreme modularity of the C++ locale system, it may well be
possible to override the interesting parts of libstdc++ with a
Windows-specific implementation, using the same underlying Windows
APIs that the MS RTL uses for C. It may even exist already, and I may
just not be aware of it ;-)