> -----Original Message-----
> From: Andy Heninger [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 11, 2000 7:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: xalan-c Problem with Xerces initialization
>
>
> 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.)
>
The simple answer is to take transcode() out of DOMString.
[Take out print() and println() while you're at it.] A string
class should just be a container for char or wchar_t. Transcoding
and printing are functions to be applied to containers.
You might want to consider moving
to wstring in place of DOMString. (You knew that was coming ;-))
>
> >
> > 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
>
>
-joe
