From: Filip KonviÄka (filip.konvicka_at_[hidden])
Date: 2007-05-28 14:52:23
>> How do you explain that the workaround works, then? When I don't send
>> any ptime to wcout, all wcin / wcout i/o works as expected, including
>> international characters (all I do is call setlocale(LC_ALL, ".OEM"); at
>> startup).
>>
> I'm not sure which workaround you're referring to I'm afraid. I didn't
> notice any call to setlocale in your example. As for why the \x161
> displays I don't know (if that is what you are saying happens). Is it a
> character available in the code page for the machine you are using?
>
The workaround is that I format ptime via wostringstream rather than
directly send it to wcout. The character \x161 displays correctly in the
first case, but does not (or, more exactly - looks differently) after
sending a ptime to wcout.
> The Unicode for the console should be able to handle the full range of
> display restricted only by the font in use. The streams implementation
> doesn't have such wide applicability though as it narrows it to eight
> bit output. All the experimentation I've done leads me to the conclusion
> that _cputws is able to display the widest range of characters properly,
> but only if you start the command shell with the Unicode handling turned on.
>
That does not matter much, I think. The "setlocale(LC_ALL, ".OEM")" call
was indeed left out from my example, as it only ensures that characters
received via wcin are correctly translated to wchar_t (I assume that the
other option is running cmd /u, thanks for the tip!). If I don't call
this, the characters that I read from the console via wcin are different
from what I see in the debugger watch window, however they are
translated to their original form when printed back to wcout. (Unless I
send a ptime to wcout, that is.)
> I'm not suggesting that this is the only possible explanation for what
> you are seeing, but it seemed a reasonable possibility given your
> description.
>
:-) I'm *not* having problems reading/writing international characters
as long as I don't send ptime to wcout.
I did some debugging on the matter and I suspect that the line
boost/date_time/posix_time/posix_time_io.hpp:61 is the culprit. It
changes the locale of wcout and whatever machinery should revert this
back, it does not. This agrees with my observation that using a
wostringstream for formatting does not damage wcout.
What do you think?
Cheers,
Filip