Rob Weir comments
>
> Having a static foo("hello world")
> seems innocuous enough. Any other string class would allow it. Since
> DOMString is the way strings are exposed by the Xalan API, users of Xalan
> will be programming with DOMString. How do we prevent them from using
> static DOMString? Of course, we know why this is bad. But will the
> average user know this?
I don't know a good answer to this problem. An earlier version of our code
did attempt to support this, and over and over we had people who had botched
the installation of the transcoding service, which caused an error during
static construction, which there was no good way to report. And no way for
applications to catch any exception thrown. (The static foo("hello world")
constructor does need to transcode the string from (char *) in the system
default code page to Unicode.)
>
> In any case, we're going to bypass the whole issue in our code by using
> static wide-character literal strings instead of DOMString's. This
depends
> on XMLCh being the same as wchar_t, which I understand is in the works.
>
Yes, this change is almost there. It's in the set of stuff that we are
currently checking out; once everything appears to be stable on all the
platforms, it'll go back into CVS. XMLCh will be settable to either wchar_t
or unsigned short by a build option, with wchar_t being the default.
It does turn out, however, that there are some portability problems with
wchar_t literal strings. On some platforms (HP), they apparently do no
always generate Unicode values, but can generate something that depends on
the current locale. I don't fully understand this yet, but we are trying to
better understand the problem.
-- Andy
