Hi,

You've maybe noticed I took up libc++ hacking again.

Last time I started adding Windows support, and in order to provide the
locale related things, I used _free_locale and _new_locale, which are in
msvcr80 and up.

Now I have a question and two alternatives:
Q: How hard would it be to implement this in a MinGW-w64 library like
mingw32 or mingwex?
Alt: How hard would it be to provide an efficient uselocale function?
Alt2: How hard would it be to provide *_l functions, which are normal
functions like isdigit etc. that take an additional parameter of type
locale_t instead of using the thread's locale. These are defined in xlocale
on BSD and Mac OS X systems, and Microsoft has them in the newer CRTs.

My current solution is located here:
https://github.com/llvm-mirror/libcxx/blob/master/include/support/win32/locale_win32.h#L37
and here:
https://github.com/llvm-mirror/libcxx/blob/master/src/support/win32/locale_win32.cpp#L16

which
1. is quite inefficient as it tries to do the right thing, but relies on
_configthreadlocale to do so.
2. relies on msvcr100+

The correct path would be to implement the *_l functions, which are quite
useful, but that is above my skill set.

Any help is much appreciated. This will allow MinGW-w64 to work independent
of GCC's C++ Standard library and allow Clang access to a feature-complete
C++11 Standard Library.

Thanks,

Ruben
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to