On 13 avr, 10:58, Barry <dhb2...@gmail.com> wrote:
himanshu.g...@gmail.com wrote:
The following std c++ program does not output the unicode
character.:-
%./a.out
en_US.UTF-8
Infinity:
%cat unicode.cpp
#include<iostream>
#include<string>
#include<locale>
int main()
{
std::wstring ws = L"Infinity: \u221E";
std::locale loc("");
std::cout << loc.name( ) << " " << std::endl;
std::wcout.imbue(loc);
std::wcout << ws << std::endl;
}
Unicode support is not included by current C++ standard,
Full Unicode support isn't there, but there are a few things.
L"\u221E", for example, is guaranteed to be the infinity sign in
an implementation defined default wide character encoding,
supposing it exists. And Posix (not C++) guarantees that the
locale "en_US.UTF-8" uses UTF-8 encoding. So at the very least,
from a quality of implementation point of view, if nothing else,
he should either get a warning from the compiler (that the
character requested character isn't available), throw
std::runtime_error to indicate that the requested locale isn't
supported, or the character he wants, correctly encoded in
UTF-8. (Technically, the behavior of locale("") is
implementation defined, and I don't think it's allowed to raise
an exception. But in this case, an implementation under a
system using the Posix locale naming conventions shouldn't
return "en_US.UTF-8" as the name, but rather something like
"C".)
What I would do in his case, for starters, is do a hex dump of
the wstring's buffer, to see exactly how L"\u221E" is encoded.
Beyond that: if it's encoded as some default character indicated
a non-supported character, then he should file an error report
with the compiler, requesting a warning, otherwise, he should
file an error report for the library, indicating that locales
aren't working as specified.
James, thanks for correcting me.
I review the standard about \u and \U.
Now I'm *sure* that my assertion about the "\u" was wrong.