Hello Boost List! ================= I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework. I'm looking forward to formal review and general inputs from Boost.Community. Documentation: http://cppcms.sourceforge.net/boost_locale/html/index.html Download: From: https://sourceforge.net/projects/cppcms/files/ File: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale.zip/... Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library giving: * Correct case conversion, case folding and normalization * Collation including support of 4 Unicode collation levels. * Date, time, timezone and calendar manipulations, formatting and parsing including transparent support of calendars other then Gregorian. * Boundary analysis for characters, words, sentences and line-breaks. * Number formatting, spelling and parsing. * Monetary formatting and parsing. * Powerful message formatting including support plural forms, using GNU catalogs. * Character set conversion. * Transparent support of 8-bit character sets like Latin1. * Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. New in this version: ==================== a. Fully redesigned break iterator interface b. Added date_time and calendar support that allow manipulating with dates over non-Gregorian calendars c. Implemented full set of unit-tests d. Added support of many platforms and compilers. e. Lots of bug fixes. f. Complete reference with Doxygen g. Many tutorial updates, thanks to Markus Raab inputs Tested compilers and platforms: =============================== - Compilers: - GCC 3.4, 4.1, 4.2, 4.3, 4.4 - Intel Compiler 11.0 - SunStudio 12 with STLPort - MSVC 2008 - Operating Systems: - Linux - FreeBSD - OpenSolaris - Windows XP - Windowns XP/Cygwin - ICU Versions: 3.6, 3.8, 4.2 Full list of tests: =================== - Linux: - Debian GNU/Linux 2.6.18, x86, GCC 4.1.2, ICU 3.6.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.3.2, ICU 3.8.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.4 -std=c++0x, ICU 3.8.1 (Some faults on char16_t/char32_t support) - Debian GNU/Linux 2.6.26, x86_64, Intel Compiler 11.0, ICU 3.8.1 - FreeBSD - FreeBSD 8.0, i386, GCC 4.2.1, ICU 3.8.1 - OpenSolaris: - SunOS OpenSolaris 5.11, i386; Sun Studio 12, with STLPort, ICU 4.2 - SunOS OpenSolaris 5.11, i386; GCC 3.4.3, ICU 4.2 - Windows XP/SP2 - Cygwin 1.5, GCC 3.4, ICU 3.8 - Cygwin 1.5, GCC 4.3, ICU 4.2 - Windows XP/SP2, Mingw/GCC 4.4, ICU 4.2 (Static build only) - Windows XP/SP2, MSVC9 (2008)
On Thu, Mar 11, 2010 at 3:47 PM, Artyom <artyomtnk@yahoo.com> wrote:
Hello Boost List! =================
I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework.
I'm looking forward to formal review and general inputs from Boost.Community.
Documentation:
http://cppcms.sourceforge.net/boost_locale/html/index.html
Download: From: https://sourceforge.net/projects/cppcms/files/ File: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale.zip/...
Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library giving:
* Correct case conversion, case folding and normalization * Collation including support of 4 Unicode collation levels. * Date, time, timezone and calendar manipulations, formatting and parsing including transparent support of calendars other then Gregorian. * Boundary analysis for characters, words, sentences and line-breaks. * Number formatting, spelling and parsing. * Monetary formatting and parsing. * Powerful message formatting including support plural forms, using GNU catalogs. * Character set conversion. * Transparent support of 8-bit character sets like Latin1. * Support of char, wchar_t and C++0x char16_t, char32_t strings and streams.
New in this version: ====================
a. Fully redesigned break iterator interface b. Added date_time and calendar support that allow manipulating with dates over non-Gregorian calendars c. Implemented full set of unit-tests d. Added support of many platforms and compilers. e. Lots of bug fixes. f. Complete reference with Doxygen g. Many tutorial updates, thanks to Markus Raab inputs
Tested compilers and platforms: ===============================
- Compilers: - GCC 3.4, 4.1, 4.2, 4.3, 4.4 - Intel Compiler 11.0 - SunStudio 12 with STLPort - MSVC 2008 - Operating Systems: - Linux - FreeBSD - OpenSolaris - Windows XP - Windowns XP/Cygwin
- ICU Versions: 3.6, 3.8, 4.2
Full list of tests: ===================
- Linux: - Debian GNU/Linux 2.6.18, x86, GCC 4.1.2, ICU 3.6.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.3.2, ICU 3.8.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.4 -std=c++0x, ICU 3.8.1 (Some faults on char16_t/char32_t support) - Debian GNU/Linux 2.6.26, x86_64, Intel Compiler 11.0, ICU 3.8.1
- FreeBSD - FreeBSD 8.0, i386, GCC 4.2.1, ICU 3.8.1
- OpenSolaris: - SunOS OpenSolaris 5.11, i386; Sun Studio 12, with STLPort, ICU 4.2 - SunOS OpenSolaris 5.11, i386; GCC 3.4.3, ICU 4.2
- Windows XP/SP2 - Cygwin 1.5, GCC 3.4, ICU 3.8 - Cygwin 1.5, GCC 4.3, ICU 4.2 - Windows XP/SP2, Mingw/GCC 4.4, ICU 4.2 (Static build only) - Windows XP/SP2, MSVC9 (2008)
This looks very nice indeed! Do you use anything in the background to handle Unicode (ICU?), or do you handle it yourself, or does it support multiple interfaces? How complete is the Unicode interaction? Is there no testing on MSVC8 (2005), if not I can test on that easily if you need it. I am definitely eager in looking at this overall framework (as well as CppCMS, I love looking at C++ web backends, we need a good one in Boost, so many things can use it), cannot wait for a review.
Hello,
This looks very nice indeed! Do you use anything in the background to handle Unicode (ICU?), or do you handle it yourself, or does it support multiple interfaces? How complete is the Unicode interaction?
I use ICU, it is quite impossible to provide anything useful without it.
Is there no testing on MSVC8 (2005), if not I can test on that easily if you need it.
I didn't tested MSVC8 (2005) because I do not have one installed. If you can test it for me you are more then Wellcome.
(as well as CppCMS, I love looking at C++ web backends, we need a good one in Boost, so many things can use it),
I just must tell that CppCMS is not planned to be part of Boost. However the part I developed for it -- localization library is developed for Boost as well. Artyom
Artyom wrote:
Hello Boost List! =================
I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework.
I'm looking forward to formal review and general inputs from Boost.Community.
Documentation:
I believe that almost the very first thing you should explain is what is added/changed between std::locale and its facets and Boost.Locale. Also since you mention date/time functionality you should explain what Boost.Locale offers compared to Boost.date_time. These are just suggestions, but when you offer a library and there are other well known similar libraries around, I think it is important to distinguish your library's functionality from others.
I believe that almost the very first thing you should explain is what is added/changed between std::locale and its facets and Boost.Locale.
It is mentioned here: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#design-rationa... Where I explain what is standard localization system is missing.
Also since you mention date/time functionality you should explain what Boost.Locale offers compared to Boost.date_time.
These are just suggestions, but when you offer a library and there are other well known similar libraries around, I think it is important to distinguish your library's functionality from others.
I mentioned it one of the first sentences here: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#working-with-d... boos::date_time works only with Gregorian calendar while boost::locale provides transparent support of many others like Hebrew, Islamic, Japanese etc. Artyom
On 3/12/2010 9:47 AM, Artyom wrote:
Hello Boost List! =================
I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework. <snip>
I don't have time to look in detail right now, but I just want to say that that this sounds GREAT. Really great. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Hi! Artyom wrote:
I am afraid the link to the tutorial (at the end of main page of doxygen) is broken, at least I get a 404: http://cppcms.sourceforge.net/boost_locale/index.html Unfortunately currently I don't have time to look at it. best regards Markus -- http://www.markus-raab.org | Demokratie ist Diskussion. -- Th. G. -o) | Masaryk Kernel 2.6.24-1-a /\ | on a x86_64 _\_v |
I am afraid the link to the tutorial (at the end of main page of doxygen) is broken, at least I get a 404: http://cppcms.sourceforge.net/boost_locale/index.html
Thanks! Fixed. In any case tutorial was accessible from top menu. Artyom
On 3/13/2010 2:56 AM, Mathias Gaunard wrote:
Artyom wrote:
Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library
That's a very interesting wrapper of ICU. It might even kill off my Unicode library.
I think Boost probably needs a Unicode library that is *not* a wrapper of ICU. What is it's license? How generic is it? (E.g. can I run Unicode algorithms over non-contiguous data?) -- Eric Niebler BoostPro Computing http://www.boostpro.com
Hello Eric,
That's a very interesting wrapper of ICU. It might even kill off my Unicode library.
I think Boost probably needs a Unicode library that is *not* a wrapper of ICU.
One of the points I considered when I was developing Boost.Locale was actually independence of ICU. You would not find any interface that exposes ICU, (even thou it is quite connected to it). In fact, for CppCMS I have its small version for embedded systems (that lacks 80% of its original abilities that work over std::locale only and it is quite useless for Boost). So it is possible to replace someday in future ICU or parts of it with other (maybe better) Unicode engine. For example, I do not use ICU Resource Bundles for message translation, I actually use GNU Gettext MO Catalogs (not runtime library). **However** developing and debugging new library that nearly close to abilities of ICU (v4.2 has about 680,000 lines of source code) requires many hundred man years and is absolutely unfeasible, unless some big company would donate their time build it (as IBM does with ICU). Please read this: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#design-rationa... So the question isn't whether Boost needs its own Unicode library, or it needs good ICU wrapper the question is whether Boost needs Unicode library at all. For the record: I remember somebody posted initial version of Unicode library that included **only** properties of characters and it didn't went much far then that. But you also need CLDR and its processing, you need dictionaries for proper break iteration and so on, implement numerous Unicode algorithms and so on. This is huge work to do. Once I did comparison of ICU with glib and Qt (big fat libraries that have lots of goodies for Unicode, neither one of them was as correct as ICU).
What is it's license?
You mean Boost.Locale? Boost license. If you ask about ICU license, it is permissive license very similar in terms to Boost, MIT and other such licenses: http://source.icu-project.org/repos/icu/icu/trunk/license.html
How generic is it? (E.g. can I run Unicode algorithms over non-contiguous data?)
Only boundary iterator provides API that allows you to work over non-continuous data but internally it is still converted to continuous. But neither ICU. It has very few classes (BreakIterator and few others) that allow you to work over non-continuous data (UText) and this is very painful in any case (UText is not very nice API). So, during design I aimed to rather correct and useful approach then totally generic and extremely efficient one. Best, Artyom
On 03/13/2010 01:53 AM, Eric Niebler wrote:
On 3/13/2010 2:56 AM, Mathias Gaunard wrote:
Artyom wrote:
Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library
That's a very interesting wrapper of ICU. It might even kill off my Unicode library.
I think Boost probably needs a Unicode library that is *not* a wrapper of ICU.
For the record, Boost already uses ICU.
What is it's license?
http://source.icu-project.org/repos/icu/icu/trunk/license.html
How generic is it? (E.g. can I run Unicode algorithms over non-contiguous data?)
From what I know, it provides streaming character conversion algorithms. Probably, other streaming algorithms exist as well. I really don't see the point in reinventing a wheel here. The code is there, it's well tested and maintained, feature rich and widely deployed. What's missing is a better C++ interface, and that's exactly what I expect from Boost.Locale. On the topic. I think, Boost.Locale will be a major and highly awaited addition to Boost. The need in Unicode support is especially strong.
<Snip>
I really don't see the point in reinventing a wheel here. The code is there, it's well tested and maintained, feature rich and widely deployed. What's missing is a better C++ interface, and that's exactly what I expect from Boost.Locale. <Snip>
Just to provide more points for Andrey's note. ICU today is de-facto standard Unicode/localization library. Even if you take a look on CLDR you will find references to ICU as **the** library that uses CLDR. The biggest ICU issue is that it was designed after Java interface. icu4j feels quite natural in Java world but icu4c API is total disaster, it is like Java translated line by line to C With Classes... (Even hardly say C++ because it does not use at all: STL, Exceptions, RTTI) Also, please, read this article: Unicode in 2009? Why is it so hard? http://art-blog.no-ip.info/cppcms/blog/post/43 I compare major Unicode toolkits available in may languages... Unfortunately every each one of them fail on quite simple task. So I think creating full featured Unicode/Localization library for Boost would be very hard when so many fail in same place. Artyom
From: Mathias Gaunard
That's a very interesting wrapper of ICU. It might even kill off my Unicode library.
I don't think so, I've been watching after this library and it was very interested in it. Note, there is quite a big difference: Boost.Locale provides **localization** centric API. I do not bother too much with character properties, I even do not provide UTF-8/16/32 code-point iterator because you are rarely need to go down to such low level. You rather need higher level abstraction: characters, words etc. Most of algorithms provided in Boost.Locale are actually locale dependent with very few exceptions:Unicode normalization, case folding and character set conversion just because they extremely important. More then that I fully support non-Unicode character sets (however I do not recommend them). So I do think that Unicode library that deals with lower level is important and they would rather complete each other then replace it. Artyom
Artyom wrote:
Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library
That's a very interesting wrapper of ICU. It might even kill off my Unicode library. One thing that has bugged me with std::locale is the mandatory locking incurred for trivial things like creating an output stream. How does
Mathias Gaunard wrote: this library behave with locking and the like? (I guess performance is not a prime consideration though.) Good luck with your library, Thanks and Best Regards, Matthew
One thing that has bugged me with std::locale is the mandatory locking incurred for trivial things like creating an output stream. How does this library behave with locking and the like? (I guess performance is not a prime consideration though.)
I use std::locale goodies as is, so if compiler uses locking then it would happen. However, std::locale implementation is very efficient and uses reference counting and global functions like std::locale::global in any case should not be used. I assume that ICU would do much more locking on its own then standard C++ library.
I guess performance is not a prime consideration though.
Yes, it is not my primary consideration.
Good luck with your library,
Thanks and Best Regards, Matthew
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello,
I'm glad to introduce updated version of Boost.Locale <snip> I'm looking forward to formal review and general inputs from Boost.Community.
Few points I forgot to mention: 1. I would like to ask from the community some inputs: a) Opinion about the library b) How is it ready for formal review? 2. Currently Boost.Locale uses CMake for build, I would really appreciate if somebody would help me to write Boost-Jam files. I'm absolutely not familiar with it, also the library is quite complex in terms of build: a) requires check for installed ICU b) requires to build with correct ICU version under MSVC (debug/release) So any help is more then welcome. BTW: do I have to provide boost-jam files before formal review? Thank you, Artyom
At Sun, 14 Mar 2010 00:55:48 -0800 (PST), Artyom wrote:
Hello,
I'm glad to introduce updated version of Boost.Locale <snip> I'm looking forward to formal review and general inputs from Boost.Community.
Few points I forgot to mention:
1. I would like to ask from the community some inputs:
a) Opinion about the library b) How is it ready for formal review?
This looks really cool. I don't know whether it's ready or not, but I hope it does come up for review eventually! That said, please do something to make it clear in the docs that it is not (yet) an actual Boost library. Thanks, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Monday, March 15, 2010 12:30 AM To: boost@lists.boost.org Subject: Re: [boost] [Boost.Locale] New Release
At Sun, 14 Mar 2010 00:55:48 -0800 (PST), Artyom wrote:
I'm glad to introduce updated version of Boost.Locale <snip> I'm looking forward to formal review and general inputs from Boost.Community.
This looks really cool. I don't know whether it's ready or not, but I hope it does come up for review eventually!
That said, please do something to make it clear in the docs that it is not (yet) an actual Boost library.
Ah - but he has - but not BOLD enough perhaps? The Boost logo says "Designed for Boost" - but it's in a rather small font. Two other possible logos are attached - but they have the 'small print' in red so you can't miss it. Previous threads on 'new logos' topic fizzled out - but I am still of the firm view that we need to reach some decision, if not agreement. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
This looks really cool. I don't know whether it's ready or not, but I hope it does come up for review eventually!
I hope so too ;)
That said, please do something to make it clear in the docs that it is not (yet) an actual Boost library.
I had added clarifications in tutorial and Doxygen page that this library is not a Boost library. Artyom
participants (10)
-
Andrey Semashev -
Artyom -
David Abrahams -
Edward Diener -
Eric Niebler -
Markus Raab -
Mathias Gaunard -
Matthew Herrmann -
OvermindDL1 -
Paul A. Bristow