Daryle Walker wrote:
It was specifically requested that some Unicode/wchar_t support be added before putting to CVS.
That doesn't mean that you _have_ to do it. You can give the person who gave the request a (temporary) rejection notice.
Well, that was requested by the review manager (while wearing review manager hat). So, given that I think it's possible to implement with little effort, I'd rather implement this.
What 'cool-sounding idea' do you mean? What I proposed was that unicode data is just passed though, without modification.
I read messages in this thread about doing full-blown Unicode handling, and I've read about doing nothing (being as Unicode-ignorant as other text-processing Boost libraries). I wouldn't mind adding "wchar_t" support, without necessarily assuming that it's Unicode.
I still plan to assume wchar_t is unicode, until some user comes up with problems in his real case.
Do you know specific case there wchar_t does not implicitly means Unicode.
Not personally, but that's about as relevant as asking for a platform whose "char" isn't 8 bits. (I've heard platforms like that have existed.)
I know one such platform which exists today, with 32-bit char. However, it (1) still uses ascii (2) you won't run string algrotithms on a DSP anyway Yes, implementation is allowed to use randomly-permuted ascii encoding. The point is that *if* user of such implementation really starts using program_options, it would be possible to accomodate that. - Volodya