I thought about that. With the generic macro, it would look like:
DOMString(XMLStrL("=\""));
So if its L prefixed, it doesn't transcode and the DOMString just gets used
to do the append operation. But, if you have an append with a raw Unicode
string, it would be more efficient to have it either be L"foo" or
DOMString("foo").
here are still legitimate uses for the more basic one that I just added,
but there might need to be one that is DOM specific. But, the problem is
that these things need to be compiler specific. I don't want the people
writing the compiler support files to have to be supporting all these funky
macros.
I guess what would be better is for the per-compiler to just define or not
define:
XML_LSTRSUPPORT
If that is defined, then XML4CDefs.hpp (which still needs to be renamed by
the way) can defined XMLStrL() for everyone to use, based on whether L
strings are supported. AND, DOM can provide one for itself that is more
specialized, based on the same information. I think that this would provide
maximum flexibility.
Oh well, I just added the macro support at the compiler file level. I guess
I'll have to undo that and go around an take back that internal message I
just sent to get everyone to add it to their per-compiler files :-)
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/13/2000 04:44:25 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: DOMString (was: xalan-c Problem with Xerces initialization)
Does the DOMString("=\"") approach work on all platforms. If so, then on
the platforms that L"" doesn't work on, you could define _XSTR(str) as
DOMString(str). It just seemed like a lot of unnecessary effort on most
platforms.
