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