Daryle Walker wrote:
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
I meant something like a 9-bit EBCDIC "char" on an older computer. (I made that up; I don't know if that case has really occurred.)
Ok, though EBCDIC is quite ancient 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.
I'd rather not have an indefinitely-ticking portability time bomb left in the code.
In fact, that's not going to be a time-bomb. I expect anyone who's going to use the library to run tests or to look at tests results, and even trivial Unicode test will catch problems on EBCDIC. What I don't want is spend time to accomodate systems: 1. Which might not exist anyone 2. Which might not have any user base 3. Which might not have good enough C++ compiler - Volodya