This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC 0/2] C++11 codecvt specializations.
- From: Rüdiger Sonderfeld <ruediger at c-plusplus dot de>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 29 Apr 2014 13:14:39 +0200
- Subject: Re: [RFC 0/2] C++11 codecvt specializations.
- Authentication-results: sourceware.org; auth=none
- References: <1640346 dot JHYN4fB8ph at descartes> <87wqe9a4r0 dot fsf at fleche dot redhat dot com>
Hello Tom,
On Monday 28 April 2014 08:49:23 Tom Tromey wrote:
> Also, some implementations of iconv cannot convert to or from the
> wchar_t encoding; though I imagine you can work around this with
> appropriate template specializations to use the <wchar.h> stuff.
It seems that the wchar.h conversion functions do not properly convert the
encoding. I used a few examples and they failed to convert non-ASCII
characters in either direction even with a UTF-8 locale.
In any case the standard code conversion facilities ([locale.stdcvt]) are only
defined with UCS2 and UCS4 in mind depending on the type. So I guess this
could be done through a template check and if wchar_t is two byte it's treated
as UCS2.
Come to think of it, those conversion facilities are rather strangely defined:
From the standard:
| Elem is the wide-character type, such as wchar_t, char16_t, or char32_t.
...
| The facet shall convert between UTF-8 multibyte sequences and UCS2 or UCS4
| (depending on the size of Elem) within the program.
Does this mean codecvt_utf8<char16_t> is supposed to convert UTF-8 to UCS2
because char16_t is two bytes or should it convert UTF-8 to the UTF-16
representation of UCS4? Looking at the code I would have expected the latter
but the standard seems to be unclear.
Regards,
RÃdiger
btw. your FOSDEM talk about GDB was very interesting!