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