Boost logo

Boost :

Subject: Re: [boost] Fw: [locale] Formal review of Boost.Locale library
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-07 09:51:22

Hello, > > > > - What is your evaluation of the documentation? > [SNIP] > > * The examples are not motivating, and just end up looking complex. > Can you be more specific? > > * I'd have liked to see examples in more languages, in particular some > Asian languages, to comfort me that the library has taken their issues > into consideration. If the itch being scratched here is just for a > couple of European languages then the library may have design flaws. Unfortunately I don't know any East-Asian Language, neither Chinese nor Japanese. So it would be very hard for me to write reasonable sane examples in these languages. I know Hebrew, Russian, English, Ukrainian so these languages are chosen for writing examples and added some other points like Arabic-Locale numbers and some other things. However with their East-Asian lingual problems, relevant unit tests include East-Asian text and I relay heavily on correctness of 3rd part libraries like ICU. > > * The backends page ( > > ) looks interesting, and may be the start of justifying the reason for > this library to exist. The biggest difference between using and not using ICU backend is linking with ICU library which weights about 18 MB on Linux/x86_64. Timings are really depend on specific cases and not always closely comparable, sometimes I find ICU faster sometimes it slower. I must admit that after recent modifications Boost.Locale's ICU backend is has comparable performance with other backends like std or posix. In may experience when I use Boost.Locale in CppCMS I almost always may use std or posix backends without particular problems. Only when I need more advanced features ICU is required part. > It could be expanded with something more > concrete: complete examples of doing something useful with different > backends, with timings and exe sizes we could compare. > Actually take a look on this table, and general examples, almost everything is usable with std or other backends however the quality and nuances are different for example whether the number 103 in ar_EG.UTF-8 locale represented as "103" or as "١٠٣" So almost all examples are valid (see the table), this is the general idea of multiple back-ends support > > - What is your evaluation of the potential usefulness of the > > library? > > I would choose to use ICU directly, as I couldn't see a reason not to, > and I'd be concerned that the wrapper would not have wrapped some > obscure function in ICU that I find I end up needing. > To answer I first point you to this: this: And also to this: And remind that not everything is implemented in terms of ICU (message translation) and allows to use successfully non-ICU backends. However, in certain cases ICU seems to be only reasonable options (and most full featured). For example on Solaris and FreeBSD were the OS and the GCC compiler does not provide reasonable locales support ICU is only usable backends. > > Darren > Thanks for the comments. Artyom

Boost list run by bdawes at, gregod at, cpdaniel at, john at