From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-07 02:49:19
Ferdinand Prantl wrote:
>> 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.
>
> Yes - that's it. There can be a locale en_US.UTF-8, and then the
> application must accept it. If it does not, it has conversion support,
> imbuable or not.
Did you mean "if it does", i.e. without "not"?
> Application should not require the library to have a
> unified encoding of char * on all environments; that's not STL style.
So, the encoding of char/string on interface boundary is determined by
locale/codecvt?
>> > 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?
>
> Yes again, now it seems to me we try to persuade each other about the same
> thing :-)
Oh, that's good :-)
Thanks,
Volodya