implying), but certainly there are alternatives. I've tried using
auto conversion stuff). I wish Windows would adopt using UTF-8 as an
internal standard. Perhaps the conversion time to display the strings is a
types would be useful as well (as we've discussed). That would breath new
Giovanni Dicanio wrote:
What do you mean with "multi-byte"? ANSI, or some local code-page?
If so, it is what I wrote in my previous post.
But I expected that in a Unicode build, CStdioFile would write using
*Unicode* (possibly UTF-16). Instead, that is not true.
In fact, in a Unicode build, CStdioFile still uses some form of local
code page ("multi-byte").
IMHO, "multibyte" (i.e. ANSI or some local code-page) is a bad format to
write text to file, because if you pass that file to a different machine
with a different default local code-page, the content of the file is
*misinterpreted*.
Instead, Unicode (UTF-16 or UTF-8) is *unique*, independent of local
code-pages.
If I have a text written in e.g. Unicode UTF-8, I can pass it to a
Japanese person who has a different code-page than the Italian one that I
have on my system, and the content of the file appears the same.
Hi Giovanni:
I have a simple rule, that has worked well fro me over the years:
Never use an MFC class unless you have to.
CArray, CMap, Clist, CFile, CSdtioFile are definitely on my list of don't
have to's. They all have better alternatives in the C++ standard library.
Although I know that C++ fstreams are not always the fastest, they have
always worked well for me, and I know exactly what they do (they do what
you tell them, without conversion tricks or other nonsense). Really, the
silent conversion between UTF16 and MBCS in many contexts is one of the
most insidious features of MFC, which will plague it forever unless some
attempt is made to deprecate it. At the very least there should be an
macro NO_SILENT_STRING_CONVERSIONS. Even better, have it #defined by
default.
One piece of craziness about C++ fstreams is that the C++ committee has
never sanctioned the use of wchar_t strings for opening them. This is
sheer insanity for an OS like Windows (NT) that uses wchar_t as its native
character type. Fortunately in VS2008 Microsoft has rebelled against this
and added this behavior as an extension.
--
David Wilkinson
Visual C++ MVP