That wouldn't be something that we would need to do. Our code,
unfortunately, doesn't assume that the L prefix capability even exists in
the universe :-) If you look at all of our constants, they are in the form:
const XMLCh gSomeString[] = { chLatin_I, chLatin_B, chLatin_M, chNull };
So we are not dependent upon any such mechanisms. As far as what the
outside world wants to do, that's up to to them, and of course VC++ defines
the _T() macro for that purpose.
If you are asking that we just define one so that client code can have one
available in a platform independent way, I have no problem with doing that.
But the parser itself has no need for one for the most part.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/05/2000 11:02:51 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Some proposals for changes to the Xerces-C system
Dean Roddey wrote:
>>3) Very importantly, things like L"SomeWideString" will be directly
>>passable to parser APIs (as long as your compiler generates Unicode code
>>points for L prefixed constants.)
Just as an aside, it would be useful to define something like the _TSTR
macro in Win32, say
#define _XMLSTR(str) L ## str
So that if you were on a platform that didn't generate Unicode for L
prefixed constants, you could fix it with a macro redefinition.
