Re: wprintf() could not display unicode chars which is > 255 to console?
- From: David Wilkinson <no-reply@xxxxxxxxxxxx>
- Date: Mon, 16 Jan 2006 10:05:35 -0500
Mihai N. wrote:
I have to say that this thread seems to be confusing outputting to a console window with formatting strings.
True. Unicode and the Windows console is a tricky business.
And my post was more like a answer to "use wcout" (Vivek)
and "use CString::Format" (joe).
None of them is a solution, because the problem is the console, not the API.
As a side-note CString::Format does not even use Unicode, it is a generic API.
What is better about any of these three as opposed to the others? Personally, I see no reason to choose non-portable code in a pure console application, so I would always go the iostream route. I do not have the book "Exceptional C++ style"; what does it have to say here? I can see that tostringstream might lose on efficiency (usually not an issue), but why is it worse for internationalization?
I know how generic text/API works :-) (http://www.mihai- nita.net/20050306b.shtml)
=======================================================
I will add CString::FormatMessage, and boost::format, then I will do the same thing with all 5 APIs:
- load a string from resources (or message catalog, or whatever, I am using a "generic" thing, GetTranslation)
- replace parameters
- display it
You tell me which gives the bigger mess.
[snip]
Thanks Mihai. I see now why the printf type API's are better than iostream for internationalization: it is because the format string itself can be internationalized.
Referring to your other post, what does backward compatibility have to do with this?
The console is used to emulate the behavior of the old DOS prompt.
And that was not Unicode, and used the OEM code page.
This is why the actual console uses OEM code page as default, even in the latest Windows versions.
And since I don't work at MS, I am not sure what is the real reason for proper Unicode support not being added to the console: "backward compatibility" and "who cares about console anymore".
I didn't know console used OEM codepage! But I guess my console projects only use ASCII characters, so it doesn't bother me too much. Maybe the 8-bit interface is required to be this way for backward DOS compatibility, but I am still shocked that the NT-type platforms do not have proper wide-character support for the console.
Thanks again.
David Wilkinson
.
- Follow-Ups:
- References:
- wprintf() could not display unicode chars which is > 255 to console?
- From: David
- Re: wprintf() could not display unicode chars which is > 255 to console?
- From: Joseph M . Newcomer
- Re: wprintf() could not display unicode chars which is > 255 to console?
- From: Mihai N.
- Re: wprintf() could not display unicode chars which is > 255 to console?
- From: David Wilkinson
- Re: wprintf() could not display unicode chars which is > 255 to console?
- From: Mihai N.
- wprintf() could not display unicode chars which is > 255 to console?
- Prev by Date: Re: Change a MS Access file (mdb) to a MS Project file (mpp)
- Next by Date: Re: Problems comming with change of Windows OS versions
- Previous by thread: Re: wprintf() could not display unicode chars which is > 255 to console?
- Next by thread: Re: wprintf() could not display unicode chars which is > 255 to console?
- Index(es):
Relevant Pages
|