
Filip Konvička wrote:
Kirit Sælensminde 26.5.2007 5:35:
Filip Konvička wrote:
Hi,
in MSVC 8.0 _UNICODE build, after I send a ptime to wcout, I can no longer print "international" characters. When I use a temporary wostringstream for printing the ptime, everything is OK. Minimal repro see below (the "2" at the end is never printed). With some characters like the "š" in the example, the output is totally cut off; with others, like "á", the codepage is changed, so the characters are displayed incorrectly.
Any suggestions?
This is a problem in the MSVC libraries. If you print a character above code 255 then the stream crashes and is good for nothing afterwards. Only std::wstringstream doesn't have this problem.
I think if you buy the Dinkumware libraries this works. The _cputws function does work as you would expect, but it can't be piped. The behaviour also changes if you run the program from a command shell with Unicode turned on ( cmd.exe /u).
I did talk to PJ Plauger about it on clc. This is what he explained:
"When you write to a wofstream, the wchar_t sequence you write gets converted to a byte sequence written to the file. How that conversion occurs depends on the codecvt facet you choose. Choose none any you get some default. In the case of VC++ the default is pretty stupid -- the first 256 codes get written as single bytes and all other wide-character codes fail to write. "
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 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.
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.
K
This is the program I was using to test things (again must be compiled
with _UNICODE):
#include <iostream>
#include