This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: UTF-16 streams
- From: Tom Cook <tom dot k dot cook at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>, libstdc++ at gcc dot gnu dot org
- Date: Fri, 6 Feb 2015 17:53:44 +1030
- Subject: Re: UTF-16 streams
- Authentication-results: sourceware.org; auth=none
- References: <CAFSh4UxRKt1=gVs7mui0nynTdGWv6rRJmEAtymAdAttmSr0gRA at mail dot gmail dot com> <CAFSh4UyXt6wkBFTc93GAuMjd_zOsdzkJOp24yy6onFY82Kn2QA at mail dot gmail dot com> <CAH6eHdTMeJkM4BAGdzew_JvAbjRLk7pQ84G8=XfoO5VDLQf-0Q at mail dot gmail dot com> <CAFSh4UychqQXbMvdRFrdob+anaGdRiEvC74MO1a6gz5hU3wFiQ at mail dot gmail dot com> <CAFSh4UwBpF825ZepBBLt0eTxwXW8FXOMqPZ2LkhCPPjZn_B+=A at mail dot gmail dot com> <CAFSh4Ux-Ycm-ag5WSvPRGWb3J9YfnK=VuakThafR3VbUb6=uDw at mail dot gmail dot com>
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.