This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: UTF-16 streams


Hi

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.

FranÃois


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]