At 10.58 05/10/2006 +0530, 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:
static void XMLString::catString (char* const target, const char* source)
static void XMLString::catString (XMLCh* const target, const XMLCh* source)
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.
Your assumption is right, but you are assuming that *ALL* the methods
have the double signature. But if you write
XMLCh buffer[200];
...
XMLString::catString(buffer, _T("..."));
it will not work without the _UNICODE macro defined, as there is no
overload that mixes XMLCh* and char*.
Alberto
