Re: [Boost-users] [date_time] UNICODE and wcout problems

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