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

[Karen Shaeffer]

On Thu, Jul 18, 2013 at 10:00:38AM +0100, David Chisnall wrote:
> 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

Hi David,
I agree. I am not aware of any application frameworks that rely on the locales provided by
the underlying system library. I am personally aware of a number of full custom application
stacks in C++ that don't rely on the underlying system library locales either. It seems to
be a concensus that teams prefer other options in place of the locales provided by system
libraries such as libstdc++, etc. I actually made an effort to use the c++11 stdlibc++
locale subsystem. But after doing my due diligence, I decided to use libicu via boost::locale.

I can appreciate your point of view. Bottom line is that folks have numerous options and
can decide which one best suits their needs. I don't think developer's can ask for more
than that.

I appreciate your comments. Thanks.

enjoy,
Karen
-- 
Karen Shaeffer
Neuralscape, Mountain View, CA 94040