On 2015-12-16 05:04, j...@wxcvbn.org wrote:
Tinker <ti...@openmailbox.org> writes:
What would the decision be based on?
I think that those points should be enough.
- good reasons to use ICU in boost, not just "I need the ICU parts of
Boost.". What would be the benefit for the ports tree?
I need normalize() to do Unicode normalization!
E.g. within locale(BC_LOCALE_UTF8).
http://www.boost.org/doc/libs/1_54_0/libs/locale/doc/html/group__convert.html
Boost.Locale requires Boost to be compiled with --with-icu ,
http://www.boost.org/doc/libs/1_59_0/libs/locale/doc/html/index.html
says:
"In order to achieve this goal Boost.Locale uses
the-state-of-the-art Unicode and Localization library: ICU -
International Components for Unicode.
Boost.Locale creates the natural glue between the C++ locales
framework, iostreams, and the powerful ICU library."
(Then it continues "Boost.Locale provides non-ICU based localization
support as well. It is based on the operating system native API or on
the standard C++ library support. Sacrificing some less important
features, Boost.Locale becomes less powerful but lighter and easier to
deploy and use library." - but, there's an issue here that the
C++/OS-bundled unicode normalization may be incomplete or broken so this
is why you want ICU.)
- someone has to do the work, and that includes checking for potential
breakage.
Right, Kirill said you are looking into this already now
Everyone just rolling thumbs or is there any real tradeoff?
You tell us. ;)
