This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: one idea for next GSoC: libstdc++ locale support based on POSIX 2008 duplocale/uselocale, etc.
- From: VÃclav Zeman <vhaisman at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 25 Nov 2013 16:24:35 +0100
- Subject: Re: one idea for next GSoC: libstdc++ locale support based on POSIX 2008 duplocale/uselocale, etc.
- Authentication-results: sourceware.org; auth=none
- References: <52928341 dot 3030409 at gmail dot com> <20131124235530 dot GR892 at tucnak dot redhat dot com> <5292F23B dot 9040508 at gmail dot com> <CAH6eHdQQmoJoFbW6XEsv4HOWDDfaiR9=yRddjKnKvirjO67U5Q at mail dot gmail dot com>
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