+1 for
typedef std::basic_string<XMLCh> DOMString;
-joe
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 13, 1999 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: PROPOSAL: DOMString
>
>
>
> How about we typedef XMLCh in the platform-specific header
> files and then
> typedef DOMString to be std::basic_string<XMLCh>. The DOM
> spec is pretty
> specific about these being 16-bit characters, so this would
> ensure it by
> default.
>
> And if someone wants to change the typedefs and recompile, they could
> create a 32-bit for efficiency, or 8-bit for ASCII-only with memory
> constraints. As you point out, no one solutions dominates
> the others. So,
> make the default be what the W3C spec says and let more
> advanced users tune
> it to their particular needs. In any case, the Xerces and Xalan code
> should assume nothing about the size of XMLCh.
>
> As for reference counting, we get that already in some
> standard library
> implementations, like Win32/VC++. Do we know if other
> important platforms
> have really poor implementations of std::basic_string<> ?
>
>
> -Rob
>
> Andy said:
>
> >With wstring there is also the question of character size. On
> >some platforms (Win32, Solaris), wchar_t is 16 bits; on others
> >(Borland on Win32, Linux) it's 32 bits. A 32 bit wchar_t
> >compatible string allows the string data to be easily passed
> >to other APIs that expect wchar_t data, but is going to cause
> >memory use problems with large documents. There doesn't seem to
> >be a good answer to this problem, even with DOMString. On the
> >32 bit character platforms, either the data is inconvenient and
> >inefficient to use, or the data is bloated. Take you pick.
>
>
