UTF-16 streams

François Dumont frs.dumont@gmail.com
Fri Feb 6 21:48:00 GMT 2015


     You need to use std::locale::global to inject the locale with the 
additional facets at the beginning of your program. Streams rely on this 
global locale per default.


On 06/02/2015 08:23, Tom Cook wrote:
> Actually have just spotted that
>      stream.imbue(std::locale(stream.getloc(), new std::num_get<char16_t>()));
> fixes the extraction of numbers, given my specialisations of ctype and
> numpunct.  This leads me to the same question as for ctype; how do I
> get char16_t streams to use these automatically rather than having to
> imbue every stream with them?
> Regards,
> Tom
> On Fri, Feb 6, 2015 at 5:36 PM, Tom Cook <tom.k.cook@gmail.com> wrote:
>> I've gone ahead and written my own specialisations of the virtual
>> members of std::ctype<char16_t> (it's a bit noddy, delegating most of
>> it to std::ctype<wchar_t>, but happy to send it through if it'd be
>> useful).  It's correct enough that the sample code in my original
>> email does what you'd expect.
>> Is there some way to get streams to use this ctype automatically,
>> without having to imbue each stream with a new locale?
>> What would I need to do to get extraction of numbers working?  I've
>> written specialisations of std::numpunct<char_16>::* and imbued the
>> stream with them, and code extracting numbers runs without throwing an
>> exception, but the resulting numbers are garbage.  Do I need to also
>> provide std::num_get<char16_t>?
>> Thanks again, and sorry if this is veering a bit into general C++
>> standard library questions,
>> Tom
>> On Thu, Feb 5, 2015 at 9:00 PM, Tom Cook <tom.k.cook@gmail.com> wrote:
>>> Confirmed that this also fails with gcc trunk (as of about 5AM UTC
>>> today).  The stack trace is the same.  Is there something I need to do
>>> to use the ctype<char16_t> you've added?
>>> Actually I can't spot that template specialisation in the trunk code
>>> (ie `grep -r 'ctype.*char16_t.*'` returns no matches, either in the
>>> source or in $HOME/gcc-5.0/include).  If you could have a look and see
>>> if it's sitting in a workspace somewhere, I'd be grateful.
>>> Regards,
>>> Tom
>>> On Thu, Feb 5, 2015 at 5:37 PM, Tom Cook <tom.k.cook@gmail.com> wrote:
>>>> Thanks, Jonathan.  I'm currently building the GCC trunk to see where it gets me.
>>>> I'm not at all certain, by the way, that the standard requires this -
>>>> I don't have ready access to a copy.
>>>> As a side note, it would be useful if
>>>> https://gcc.gnu.org/wiki/InstallingGCC mentioned whether the build
>>>> works using eg 'make -j 5'.
>>>> Regards,
>>>> Tom
>>>> On Thu, Feb 5, 2015 at 3:15 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>>> On 4 February 2015 at 23:38, Tom Cook wrote:
>>>>>> A more specific question: is providing a specialisation of std::ctype
>>>>>> (ie std::ctype<char16_t>) the right way to fix this?
>>>>> I've just used an online compiler that provides GCC trunk and still
>>>>> get a bad_cast exception. It doesn't compile using Clang and libc++,
>>>>> so it might be that your program is not required to work and you do
>>>>> need to provide some user-defined specializations.
>>>>> I won't be able to check the standard or debug it until next week.

More information about the Libstdc++ mailing list