I've now added the following:
1) If the compiler supports L"" prefixes, then its per-compiler file
defines XML_LSTRSUPPORT.
2) XML4CDefs.hpp now defines XMLStrL() in the platform independent code,
using the setting of XML_LSTRSUPPORT provided by the per-compiler file. So
there is now a basic L or no L macro.
If DOM wants to add anything that optimizes the way DOM does transcoding,
this can be added specifically to the DOMString header, and can also base
its own macros on XML_LSTRSUPPORT being defined or not. So no one outside
of DOM has get involved with defining such macros. The per-compiler file's
complete obligation is to indicate whether it can do L"" strings or not.
So I did not define any DOM specific macros. I'll leave that to you and
Andy to come up with what you want. But an obvious scenario would be:
#if defined(XML_LSTRSUPPORT)
#define DOMStrL(str) L##str
#else
#define DOMStrL(str) DOMString(str)
#endif
Then you could do:
str.Append(DOMStrL("foo"));
which would either create a DOMString which transcodes "foo" and append
that (then throw away the temp), or (if XML_LSTRSUPPORT is defined) it
would just directly append L"foo".
Is that not what you are trying to accomplish?
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/13/2000 05:39:20 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: DOMString (was: xalan-c Problem with Xerces initialization)
Actually, maybe we are going in circles. Let me walk through what I was
thinking and check if it is the same that you were thinking.
We have this fragment of code in Xerces right now
DOMString AttrImpl::toString()
{
DOMString retString;
retString.appendData(name);
retString.appendData(DOMString("=\""));
retString.appendData(getValue());
retString.appendData(DOMString("\""));
return retString;
}
What I was suggesting was to rewrite it like
DOMString AttrImpl::toString()
{
DOMString retString;
retString.appendData(name);
retString.appendData(_XSTR("=\""));
retString.appendData(getValue());
retString.appendData(_XSTR("\""));
return retString;
}
On platforms where wchar_t is unicode then
#define _XSTR(str) L ## str
Eliminates the DOMString constructor and the ASCII to Unicode conversion
Only platforms where wchar_t is not unicode I suggested we could use
#define _XSTR(str) DOMString(str)
or alternatively
#define _XSTR(str) DOMString(L ## str)
which generates the code that we had initially.
Now you made the point that we might want to use _XSTR in non-DOM portions
of the code, so DOMString would not be appropriate. We could depend on the
header author to write some appropriate definition implementation for his
platform. Whatever he does is going to be more efficient than what is in
there currently and is only run on those platforms that need to do an
explicit wide to unicode.
I'm going to continue to push on my std semantics push and maybe we can
pull
all these things together in one big issue.
