Re: [boost] [locale] review

Subject: Re: [boost] [locale] review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-04-18 10:15:25

Artyom wrote:
> From: Phil Endecott <spam_from_boost_dev_at_[hidden]>
>
> > Use of strings rather than  symbols:
> > there are a few places where the library
> > uses strings such as "UTF-8"  or "de_DE.UTF8"
> > rather than symbols like utf_8 or de_DE_UTF8.
> > This use of  strings can make things run-time errors
> > that could otherwise be compile-time  errors.
> > Mis-typing e.g. "UTF_8" or "de-DE" is too easy.
> > Perhasp in  some cases the domain of the parameter
> > is not known at compile time, but even in  those cases,
> > it should be possible to provide symbols for the most
> > common  choices.
>
> What most common choices? There are few dozen of different
> character encodings, there are even more locales, and what
> considered common?
>
> Also not all encodings are supported by all backends. For example
> iconv would not handle some windows codepages and MultiByteTo..
> would not handle some other encodings.
>
> Locales, Is de_DE.UTF-8 common? Is he_IL.UTF-8 common?
> Is zh_CN.UTF-8 common?
>
> Also the level of support by different backends may depend
> on actually OS configuration - if some locale is not configured
> on Windows or Linux that non-ICU backends would fallback to
> the C/POSIX locale.
>
> 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?  The idea being that one could instantiate the encoding object from a string and the constructor could throw an exception to indicate an unsupported encoding.  Then, one can reuse the encoding object thereafter with no further runtime cost.  Thus, APIs would expect an encoding object, not a string, but if the encoding constructor is not explicit, the effect would be the same.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.