Re: can't convert from type A* to type B*
On Monday, May 27, 2013 3:39:11 AM UTC+1, =D6=F6 Tiib wrote:
On Monday, 27 May 2013 04:45:15 UTC+3, Nobody wrote:
On Sun, 26 May 2013 16:42:22 -0700, =D6=F6 Tiib wrote:
What Microsoft's funny TCHAR etc. do is let you, with care, write a=
program that will function in both narrow and unicode implementation=
s.
Wasted care. Windows ansi functions (names with A at end) are
converting wrapper around unicode functions (names with W at end)
so "narrow" means overhead for no gain.
That is the case in current versions of Windows, but it wasn't always t=
hat
way. TCHAR originated when Microsoft was still selling versions of Wind=
ows
which didn't support Unicode. Binaries which use the W versions won't r=
un
on 95/98/ME (at least, not without unicows.dll, which didn't appear on =
the
scene until after ME was released).
Yes it was not always wasted care, however at current moment it lets you
to do something with care that is basically wasted care. ;-)
Even Microsoft itself agrees: "The TEXT and TCHAR macros are less useful =
today,
because all applications should use Unicode. However, you might see them
in older code and in some of the MSDN code examples."
http://msdn.microsoft.com/en-us/library/ff381407%28VS.85%29.aspx
It's interesting that I write a lot of code which supports
Unicode, but never uses anything other than char. As I said, I
think this is a case of Microsoft trying to do the right thing,
but not understanding all of the real issues. Anyone concerned
with internationalization, be it under Windows or under Unix,
will use UTF-8 on plain char at the external interface, and
depending on what they are doing inside the code, either UTF-8
or UTF-32 (on uint_least32_t, or char32_t if they have C++11).
--
James