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.
