UTF-16 streams

Tom Cook tom.k.cook@gmail.com
Fri Feb 6 07:23:00 GMT 2015

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?


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