Subject: Re: [boost] [locale] review
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-19 07:57:30
> Rob Stewart wrote:
> > > >
> > > > So should there be hard coded constants for locales and
> > > > encodings?
> > >
> > > If there is any runtime cost associated with the string
> > > representation, could you use a type to represent the
> > > encoding? [snip]
> > >
> > > Thus, APIs would expect an encoding object, not a string,
> > > but if the encoding constructor is not explicit, the effect
> > > would be the same.
> >
> > I'm not sure I fully understand you but...
>
> [snip]
> My suggestion was, if it fits the library, to create a class representing the
>encoding.
> With my suggestion, encoding validation is done in just one place: the
>encoding class' constructor.
In Boost.Locale scope it works this way:
1. You create a locale:
boost::locale::generator gen;
std::locale myloc = gen("de_DE.ISO-8859-15") // latin1 with Euro sign;
gen creates numerous object that handle operations, dictionaries,
collators and so on;
2. You use this locale and it already has its own encoding
std::string a,b;
// compare if a < b when a,b are in ISO-8859-15
bool less = myloc(a,b);
if(less) {
// std::cout uses ISO-8859-15
std::cout.imbue(myloc);
// messages formatted in ISO-8859-15
std::cout << format(translate("{1} sorted before {2}")) % a % b;
// gettext creates a message in ISO-8859-15 according to myloc's encoding
MessageBox(gettext("All sorted out",myloc).c_str());
}
So basically you almost never use encoding name directly unless
you do charset conversion from some forgain character set.
Because encoding information is kept together with the std::locale
object and validated during generation of the locale.
That is why there is no need for specific encoding object
in Boost.Locale's scope.
Artyom