On 25 November 2013 13:09, Jonathan Wakely wrote: > On 25 November 2013 06:46, Václav Zeman wrote: >> On 11/25/2013 12:55 AM, Jakub Jelinek wrote: >>> On Sun, Nov 24, 2013 at 11:52:49PM +0100, Václav Zeman wrote: >>>> Here is one idea for GSoC: Implement C++ locale support in libstdc++ >>>> based on POSIX 2008 uselocale()/duplocale() facilities. > > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585 and various > posts I've made to the libstdc++ list discussing the same thing. > >>> Doesn't glibc do that since 2002? >> >> Glibc does seem to have the locale facilities mentioned above. Since >> when does it have the facilities? I do not know. Are they used in >> libstdc++'s `std::locale` implementation? Yes and no. The 'gnu' style > > Which is the default on *-gnu targets. > >> (`--enable-clocale=gnu` configure option[1]) implementation uses the >> POSIX 2008 functions but it also uses `typedef __locale_t __c_locale`, >> i.e., the Glibc internal type instead of `locale_t`. The implementation >> in `libstdc++-v3/config/locale/gnu` is also riddled with Glibc version >> checking preprocessor directives. > > Why is that a problem in practice?
It is not a problem for GNU platforms. The point was that the code while being close what POSIX 2008 based code would use is usless for non-GNU platforms as it uses Glibc internal symbols and preprocessor tests. > Even if we add a new locale model, we won't get rid of the gnu one, so > won't be able to clean up that code significantly. Nobody said anything about cleaning ups. > >> What I am proposing is that somebody takes the pure POSIX 2008 API and >> implements `std::locale` on top of that. > > This would be helpful for non-GNU platforms, but would not add any > functionality for glibc-based targets, which already have a fully > functional <locale> implementation using the GNU-specific features. True. That is why I am proposing this as a GSoC task so that non-GNU platforms like said FreeBSD and Darwin have decent C++ locale support based on POSIX 2008 API. -- VZ
