Re: can't convert from type A* to type B*
On Thursday, May 30, 2013 10:28:45 AM UTC+1, =D6=F6 Tiib wrote:
On Thursday, 30 May 2013 00:57:28 UTC+3, James Kanze wrote:
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, writ=
e a
program that will function in both narrow and unicode
implementations.
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 that way. TCHAR originated when Microsoft
was still selling versions of Windows which didn't
support Unicode. Binaries which use the W versions won't
run 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
What each module does is basically input, processing and
output. Input and output are often interactive so they are called
together as "interface".
What a module can use in interface for texts depends how the
interface is specified.
Various text-based interfaces (XML, JSON) use UTF-8.
Microsoft's language-neutral COM interfaces use UTF-16 BSTR. It
is painful to use UTF-8 instead there.
If you're interfacing to some external functions, then you
obviously have to use the encoding format which they require.
As of internally for text processing inside of the module, use
consistently one Unicode encoding. It is straightforward how to
convert it into some other Unicode encoding. UTF-8 is most
natural choice. Maybe that was what you meant by that you
never use anything but char? As of illusions with UTF-16 ...
just do not have wrong illusions with it and everything works.
Just a nit (because I think we really agree here), but there is
only one Unicode encoding. What you mean is the encoding form:
how the encoding is represented. Depending on what you are
doing, you may choose different encoding forms. For anything
external, you should use UTF-8. For interfacing with a third
party library, you must use the form that the library expects.
Internally, depending on what you are doing, it may be more
convenient to convert the UTF-8 to UTF-32. Or not: there's a
lot you can effectively do in UTF-8.
--
James