Why it may be best to avoid the CRT, in the console at least

by Michael S. Kaplan, published on 2011/06/08 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/06/08/10172411.aspx


Back at the very end of 2010, over in the Suggestion Box, Jeremy D. asked:

In a followup to Myth busting in the console talking about _O_U16TEXT for the CRT to output Unicode, why not talk a bit about how the C++ runtime (ie, iostreams) deal with Unicode.  For example, in VC2005 with the following test program:

int wmain(int argc, wchar_t** argv) {
    _setmode(_fileno(stdout), _O_U16TEXT);
    std::wcout << L"Testing 123" << std::endl;
    return 0;
}

All I get output is "T".

After some stepping through the code being called, I can boil it down to the following test case failing:

int wmain(int argc, wchar_t** argv) {
    _setmode(_fileno(stdout), _O_U16TEXT);
    assert(fputwc(L'T', stdout) != WEOF);
    return 0;
}

Is it myth #14 that iostream doesn't support Unicode?

And then, a little while later, Jeremy D added:

...it seems the behavior I was seeing is VC2005-specific.  2008 and 2010 are working fine.  Ah, bugs...

I suppose I could have just deleted the whole thing since the mystery had been solved.

But I wanted to underscore a few points:

In my opinion, it might be best to do it all with eiher Win32 or the PowerShell ISE. Unless you want to just keep reporting CRT bugs here as you find them.....


Joshua on 13 Jun 2011 9:13 AM:

The back-compatibility chain goes back here so far that I'm really not surprised this broke (the old spec was 7bit, everything else on top of it was a set of choices that were not made coherently to begin with).

Michael S. Kaplan on 13 Jun 2011 10:09 AM:

Technically these Unicode functions have been broken since birth, which might be why they feel okay fixing these problems as they find them. :-)


go to newer or older post, or back to index or month or day