Re: [boost] [locale] review

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