Boost logo

Boost :

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
> 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
     // 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.


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