Subject: Re: [boost] [locale] Off-list review of Boost.Locale library
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-16 15:40:24
> Translate GETTEXT might be better in a separate library to increase
> degrees of freedom and reduce coupling.
message translation is generally integrated part of localization, so I don't
see a reason to separate it.
Also, loading gettext dictionaries require locale information that only
> --- What is your evaluation of the implementation?
> The wrapper/backend strategy provides immediate benefit while leaving
> the door open to progressive reimplementation.
> Since it is a wrapper, could PARTS of it be implemented as a header
- It is not "just a wrapper" it is a wrapper over several APIs:
- Win32 API
- std::locale API
- When you deal with locale facets you have to have
a unique object std::locale::id per facet and when working
with DLL platform it means that you have to put it into DLL
so it would be unique for all other dlls.
So there is no way and no really a reason to do this.
- It is important for localization library to be lightweight
in terms of compilation. Because it is likely going to be
used in many parts of code.
So using light headers and heavy sources has important
strategic impact on adopting this library.
> --- What is your evaluation of the potential usefulness of the library?
> This library is potentially *extremely* useful because it LEVERAGES an
> important chunk of standard C++ that is sadly underutilised merely due
> to a few design and implementation flaws.
> This library has potential something of the order of Boost.FileSystem.
> This is a VERY strategic library and any shortcomings will be resolved
> with time.
I'm glad to hear.
> --- Do you think the library should be accepted as a Boost library?
> YES - It is relatively small but has a massive effect. It has a very low
> cost/benefit ratio since it leverages long standing classic C++ locale
Thanks, for the review and the vote.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk