Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-06 08:48:02


Dale Peakall wrote:

>> So that, there will be variants accepting char and wchar_t data types,
>> and all possible unicode problems will be addressed by char_traits and
>> locale.
>
> I have to agree. Programs should internally work in terms of
> fixed-width character sets. When string data needs to be imported/
> exported locales should be used to perform the transformation.
>
> I would make program_options support an imbue() function that
> allows a locale to be specified (otherwise use the default locale)
> and template any functions that need to process strings on the
> character type.

Why bother? As I've indicated, internal processing will work just fine with
UTF-8, and no interface of the library will expose a UTF-8 encoded string.

imbue() is a good thing for specifying what encoding char** input has, but
it's orthogonal to the rest of the library -- it's used only on interface
boundary.

> This provides much more flexibility than just supporting UTF-8.
> UTF-8 is a really impractical encoding for almost any locale where the
> majority of text is not ASCII like and the user may well prefer to
> encode text is Shift-JIS or other encodings.

Again, in my case the user does not use UTF-8 string, so why would he care
how the strings are encoded internally?

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk