Here's what I'm hearing as the current proposal:
#if defined(XML_LSTRSUPPORT)
#define DOMStrL(str) L##str
#else
#define DOMStrL(str) DOMString(str)
#endif
But, this causes DOMStrL to evaluate to different types on different
platforms. DOMStringL("hello world") could be either a const wchar_t* or a
DOMString. This sets off warning bells in my head.
Take this code for example:
void foo(XMLCh*);
foo(DOMStrL("hello world"));
This will compile and run without errors when LSTRSUPPORT is defined, but
will not compile on other systems.
One way to remedy this is to use these macros:
#if defined(XML_LSTRSUPPORT)
#define DOMStrL(str) DOMString(L##str)
#else
#define DOMStrL(str) DOMString(str)
#endif
With these, the call to foo(XMLCh*) will give a compile error on both
platforms, and this is better, since we'll catch problems like this
earlier. But, this isn't a great solution, because we lose the
optimization of avoiding the temporary DOMString when LSTRSUPPORT is
defined.
If DOMString had a conversion operator, i.e. operator const XMLCh*() const,
then we could keep the original macros and the temporary DOMString would
only occur where LSTRSUPPORT was not defined.
Or, we could get fancy and make a new class with conversions to both
DOMString and XMLCh* like this:
class TranscoderUtil
{
TranscoderUtil(const char*);
operator XMLCh*() const;
operator DOMString() const;
}
#if defined(XML_LSTRSUPPORT)
#define DOMStrL(str) L##str
#else
#define DOMStrL(str) (TranscoderUtil(str))
#endif
This will allow DOMStrL("hello world") to be used as DOMString's as well as
const XMLCh*, the same whether or not XML_LSTRSUPPORT is defined. Lazy
evaluation and inlining can make this quite efficient.
But even that is not bullet-proof, since the lifetime of temporaries in C++
constrains how long the return value of the conversion operators will be
valid, so:
void foo(XMLCh*);
foo(DOMStrL("hello world"));
would be OK, but:
XMLCh* str = DOMStrL("hello world"));
.
.
.
foo(str);
could fail in mysterious ways.
I guess the meta-question is this: do we want a solution that encompasses
SAX and XMLCh*, or just DOM and DOMString? It seems that the differences
in the representation of L"foo" is going to effect SAX as well. And Xalan
uses both.
-Rob
