Boost logo

Boost :

Subject: Re: [boost] [locale] Formal review of Boost.Locale library -- final days
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-22 05:06:15

> From: Vicente BOTET <vicente.botet_at_[hidden]> > > I don't want to see yet another date-time library > in Boost hidden inside a library as local, if we > need a better Date-Time library either the current > one needs to be updated or a new one must be proposed > as a standalone library ensuring that it is better > than the current one. See my other posts. > There are two problems with this statement: a) Date-Time by its nature is locale dependent, so it should be part of localization system and in fact it is in other libraries like Qt. There is a current very good date time library that is suitable for handling Gregorian calendar but it is not sufficient for Localization where the calendar can be non-Gregorian. Also I don't see anybody who would ever implement for boost dozen of different calendars supported by Boost.Locale via ICU. And for the record in my country - Israel I agree that Timezone handing in Boost.DateTime should be improved but this is in TODO list for years and hadn't moved to far since then. b) I don't see a problem with alternative library for Date-Time handling as there are Boost.Lambda and Boost.Pheonix and there are several parsing libraries. I don't think there is a problem with it. > > - What is your evaluation of the design? > > I don't like the OO design. I think that a more > generic approach could be applied to this domain, > and add a dynamic approach in top of the static one. > I can say one thing, when it comes to localization, you should do as few assumptions as possible, for example current std::num_put and std::numpunct does too many assumptions about the way numbers look like not allowing to do full range localization. So as more dynamic approach is used there is a better chance that it would support the culture you do not know. > Even if the library is presented as a > C++ wrapper to some useful libraries, > the interface is not enough independent > from them (See my post on gettext interface). > The interface must be independent of the back > end and more in line with the modern C++ ≈facilities. > The interface is quite standard and similar for all localization libraries around. > The DateTime part is not at the level I would expect and needs to be extracted >and improved. > See notes above. > And finally, every review should answer this question: > > - Do you think the library should be accepted as a Boost library? > > I don't think the library should be accepted as it is now. > The library should be redesigned with a generic approach This would not happen, it is the current design and it suits localization needs. It would not be "template" library. > and the interfaces be more user friendly and safe. You hadn't mentioned (apart of gettext) where interfaces are not friendly or save. Mode details would allow be to answer or improve them if the requests are reasonable. > Best, > Vicente Thank you for the review. Artyom

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