[cfe-dev] [libc++] FYI: FreeBSD libc++ status

[David Chisnall]

On 17 Jul 2013, at 19:51, Karen Shaeffer <shaeffer at neuralscape.com> wrote:

> Yes, libicu is a very significant dependency, but it all just works for every locale and every
> facet. I can only speak about the g++ c++11 libstdc++-4.7.2 locale support. It has serious
> limitations. The boost::locale documentation discusses a few of them.

ICU would be an unacceptable dependency for the FreeBSD base system.  It is also massively overkill for the requirements of <locale>, which were carefully designed to only rely on existing POSIX libc features.  FreeBSD and Darwin libc both implement all of the required features and glibc probably will soon, if it doesn't already: they're all in POSIX2008.  There may be errors in your operating system's locale files (the libc++ test suite has so far found errors in both FreeBSD and OS X locale descriptions), but I have also found errors in the locale descriptions shipped with ICU (especially in date formats), so using ICU would not be a panacea here either - especially as newer versions of ICU have managed to fix some errors and introduce new ones, so you would not even guarantee consistent errors across platforms.

ICU would also be a circular dependency for libc++, as ICU uses STL internally.

> I suggest folks ought to examine the boost::locale implementation. It is just a wrapper around
> libicu. I use it and am quite pleased. I get all the advantages of libicu without ever needing
> to maintain any of it. while it might not be appropriate for clang, I do believe it is an
> excellent example of how clang might develop it's own wrapper around libicu, alleviating any
> need to maintain it. Just a suggestion. Not my issue.

I'd strongly recommend using ICU for any GUI code that requires localisation, however this is something that you typically get for free from your GUI toolkit, as most of them use ICU internally.  As such, there is little benefit in adopting it for libc++, as people who actually care significantly about localisation will bypass <locale> and use ICU directly.  All that we would be doing is adding an extra dependency for code that doesn't depend on localisation.

David