Hi Volodya,
From: Vladimir Prus [mailto:ghost@cs.msu.su]
I would make program_options support an imbue() function that allows a locale to be specified (otherwise use the default locale)
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. Application should not require the library to have a unified encoding of char * on all environments; that's not STL style.
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.
Yes, that's also my opinion.
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 :-) Ferda
- Volodya