Debashis Tripathy wrote:
Alberto, thanks.
Jesse, could you please be a little more precise as to why the _T() macro
strings will be broken? As per my understanding, it is always better to use
_T("my string"). If _UNICODE is defined, then this will be taken as L"my
string" at compile time. If _UNICODE is not defined (ie for ANSI or MBCS) -
it will be treated as the plain literal string "my string".
My understanding (from the API documentation) is that most XERCES routines
have an unicode-compatible overloaded method. For eg, in case of
XMLString::catString() method, the available signatures are:
Many, but not all.
static void XMLString::catString (char* const target, const char* source)
static void XMLString::catString (XMLCh* const target, const XMLCh* source)
I can imagine a case where you would try to use catString() with a constant
string from your application, and a wide string from Xerces-C. If you
didn't define _UNICODE, you would need an overload like this:
static void XMLString::catString (XMLCh* const target, const char* source)
Since that overload doesn't exist, your code would not compile without
defining _UNICODE.
Now if I declare one of the parameters (say the source string) as
_T("...."), then for _UNICODE it will be a L"....", which will be
treated as
"const XMLCh*". This will invoke the second function. If _UNICODE is not
defined, then it will map to "const char*" and the first one (of the two
overloaded functions above) will be invoked.
Please let me know if I am wrong in my assumption.
Since Xerces-C always operates internally in Unicode, regardless of the
_UNICODE macro, you gain nothing by using the _T macro, and sacrifice
performance by transcoding strings at run-time, rather than at compile-time.
Also, because your application can run in a different code page from the
one that you compiled with, unless you limit yourself to a small subset of
invariant characters, local code page transcoding may cause problems.
Dave
