18

I'm considering using ICU or Boost Locale.

What are the pros and cons of each?

I understand both use ICU, but ICU is hidden by Boost Locale. According to Boost Locale's rationale page: "...the entire ICU API is hidden behind opaque pointers and users have no access to it."

Please consider new Unicode features in C++11 when comparing these libraries.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524

3 Answers3

16

ICU is very good library but it has drawbacks:

  1. The API is horrible in terms of modern C++ design and it does not work well with the standard C++ library
  2. It is UTF-16 oriented
  3. It's message translation tools are far from perfect, that is why Boost.Locale uses Gettext model

See: http://www.boost.org/doc/libs/1_49_0/libs/locale/doc/html/rationale.html#why_icu

Boost.Locale makes Localization in C++ way and also allows to uses other back-ends besides ICU (of course ICU is better) such that in many cases Boost.Locale provides you better localization alternative as it is simpler, designed for modern C++ and generally easier to use.

Of course if you need very sophisticated algorithms that are not supported by Boost.Locale or all what is your application does is Unicode processing then ICU may be better, other than that Boost.Locale is better for localizing C++ applications.

Artyom
  • 31,019
  • 21
  • 127
  • 215
  • I like the Boost Locale interface but need access to other ICU functions such as u_isalpha() or u_isalnum() that I think are not accesible through Boost Locale, unless I overlooked something. If not, do you plan to wrap those functions into Boost Locale? – Caroline Beltran Oct 10 '14 at 19:26
4

Boost.Locale uses ICU as its default backend. Some other backends can be used by Boost.Locale as well. You can consider Boost.Locale to be better interface to ICU.

Paweł Bylica
  • 3,780
  • 1
  • 31
  • 44
2

ICU was designed by internationalization experts, while boost was designed by C++ programmers.

Although strong and elegant C++, boost gets a lot of the internationalization wrong. Now, boost is a big collection of libraries, and some do better than others. But ICU is solid throughout, and it is used as a foundation by pretty much everybody except Microsoft.

So if you want solid internationalization, go with ICU. If you want cutting edge C++ (but i18n kind of shaky), go boost.

Mihai Nita
  • 5,547
  • 27
  • 27
  • Very good summary, definitely +1. Note that "Kind of shaky" internationalization might be ok if you only need fairly simple/basic stuff. Not every application needs something like ICU for its i18n. And ICU's C++ API is fairly painful, if you're used to modern C++/Boost style. – jalf Mar 04 '12 at 12:01
  • 18
    -1. The OP wants a comparison between ICU and *Boost.locale*. Saying stuff like 'boost gets a lot of the internationalization wrong [...] boost is a big collection of libraries, and some do better than others" is completely beside the point. Boost.locale is a library supposed to wrap ICU and GNUGettext, the question is how well ? Would it be better to use directly ICU or not ? – Arzar Mar 04 '12 at 12:48
  • 4
    The answer is kind of implied: ICU directly. Since Boost.locale is a wrapper, it can only be as good as ICU or worse. It might look like better C++ than ICU, but might also introduce extra bugs (I know of situations where the Mac OS X API wrapping ICU introduced bugs that are not in ICU). Also, Boost.locale goes UTF-8 all the way. Since ICU works on UTF-16, it means that all the calls have to do UTF-8 to UTF-16 conversion and back, map strings offsets, etc. A performance hit, and error prone. – Mihai Nita Mar 05 '12 at 10:17
  • 1
    It appears as though, with C++11, you can use std::u16string and UTF-16 with Boost.locale. However, according to [the status of C++0x char16_t/char32_t support](http://www.boost.org/doc/libs/1_49_0/libs/locale/doc/html/status_of_cpp0x_characters_support.html) page, "support of C++0x char16_t and char32_t is experimental." –  Mar 07 '12 at 04:00
  • 6
    @MihaiNita: Sounds like you are spreading some good old FUD. Sure, the library can contain bugs, but these bugs are more likely to be found and fixed by the community than bugs in user code. On the plus-side of using a well designed and modern library as Boost.Locale is that bugs in user code may as well be fewer than using ICU directly. – dalle Feb 19 '13 at 21:26
  • @dalle: I am not talking about bugs here. A bug means trying to get it right, but not succeeding. Most of the boost sub-libraries don't consider i18n at all. They are broken by design. – Mihai Nita Jun 27 '13 at 17:51
  • 1
    boost.locale has good support for i18n. Better than any other boost library (especially boost.date_time) so this answer currently does nothing but serve as misdirection. – nurettin May 08 '14 at 08:44
  • 5
    These are severe criticisms of Boost.Locale. For example, *Most of the boost sub-libraries don't consider i18n at all. They are broken by design.* For such strong statements, an **example** is in order. What are the design flaws of Boost.Locale that make it "broken by design"? As it stands, I have to perform my first internationalization migration, and I came here looking for advice regarding whether it is a good idea to use Boost.Locale, or whether I should use ICU directly. Unfortunately, your criticism is not **usable** for me because you've provided no evidence. Perhaps you could fill in? – Dan Nissenbaum Jan 04 '15 at 15:30