Re: isupper and islower for wstring
Goran <goran.pusic@gmail.com> wrote in
news:6eae1937-6464-4ebe-ae30-549fc537f1f1@g19g2000yqg.googlegroups.com:
On Dec 10, 4:13?am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
About the only meaning of "Unicode app" in MSVC
is that the 'W' variants are used for string-specific functions.
"Unicode app" rather means "my application supports text in any
language you throw at it, and can mix several languages in one single
text". The "W" APIs are a tool to get Unicode (through UTF-16LE, as
that's what "W" APIs work with), a consequence, if you will. Hardly
"about the only meaning".
I was specifically referring to the "Use Unicode character set" setting
present in MSVC project configurations. For supporting Unicode in general
there are of course multiple ways, I am preferring UTF-8 myself.
This is
done by some macro trickery with all the pitfalls of macros.
Pretty much ANYTHING in programming has pitfalls, but advantages, too.
In case of A/W variants of APIs, advantage is that you don't see
gibberish at the end of function names, and you can go from MBCS to
Unicode more easily. And if your own code is correct in the first
place, there is no "macro pitfall" with A/W functions. If you think
there is, show it.
So if I always
call the 'W' or 'A' variants explicitly as needed there is no need to
mar
k
the application as Unicode (or not) and as a bonus I can #undef all
the conflicting macros. Another bonus is that the code will not
change meanin
g
silently if somebody defines or undefines UNICODE.
Many consider this ability to change a bonus (admittedly, much smaller
today; anything should just be compiled with UNICODE/_UNICODE, and
reach for MBCS function variants only in rare language-specific
cases).
All in all, I think that you're doing it wrong, you are making it more
complicated for yourself, and you're making it strange for other
people who are used to A/W APIs. If your code is your personal
project, OK, but if you're in a team, I think you should step back and
reconsider your opinions.
My programs are portable to Linux/MacOSX and all strings are internally
in UTF-8. Interfacing with Windows system calls typically looks something
like:
std::string name = ...;
HANDLE f = ::CreateFileW(Utf2Win(name).c_str(), GENERIC_READ,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
-- or --
//...
} catch(const std::exception& e) {
::MessageBoxW(NULL, Utf2Win(e.what()).c_str(), L"Error in baseutil
load", MB_OK);
}
The Utf2Win() function converts from UTF-8 to UTF-16 for Windows wide
character API-s. This is done only on application boundary. I do not see
any gain in defining UNICODE and relying on macro trickery to achieve the
exact same code what I have written here.
Note that I'm not using MFC, this would probably change the rules of the
game.
Cheers
Paavo