Re: Are _T() and TEXT() macros equivalent?
"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message
news:Xns9910DC6A64371MihaiN@207.46.248.16...
Your option:
- The old programs need changes
- For new ones is easy to use char as Unicode character
- The result is not standard
- The result is not cross-platform
Current option:
- The old programs need changes
- For new ones is easy to use wchar_t as Unicode character
- The result is standard
- The result is cross-platform
All this to avoid macros?
If it's this much trouble to get rid of something as minor as _T() macros,
then I don't even want to talk about bigger innovations. It just shows how
stuck in the mud C++ programmers are. To say that it is FUNDAMENTAL to the
language that sizeof(char) == 1? I mean, really.
Again, existing files would have to be converted, or else code to
read/write them have to specifically use one byte chars.
You cannot convert legacy files. Legacy files don't mean "files I have
saved
a while ago"
It also means any other files out there that are not Unicode UTF-16LE,
what is called import/export. Think HTML, XML, text.
Well yes. If I know a file is not saved in Unicode, of course we need
special routines to read it and convert it, but what has that got to do with
whether a native "char" is 1 byte or 2 bytes? There is a separate thread
going on about how CStdioFile does not really read Unicode-16 files
properly. So we need to write some new code to read Unicode-16 files into
wide strings. Big deal. It's not like we're saying because CStdioFile
doesn't work with Unicode-16 files, that the whole Unicode concept is
faulty.
And strcpy_s is a non-standard, non-portable extension.
It does not change the functionality of strcpy, which is standard.
I had thought strcpy_s was the new standard. If it's not, it's even less of
a draw than before. In my mind, it doesn't hold a candle to strsafe.
-- David