Regarding DOMSTring, Joe Gregorio wrote:
>1. Don't change anything (except maybe add a larger red flag
> in the documentation).
>2. Change DOMString to have value semantics.
>3. Drop DOMString in favor of wstring.
>
>Personally, I would prefer 3, but 2 is probably
>the most reasonable given the current state of
>Standard C++ libraries.
Robert Weir replied
> I like option #3. Perhaps even make it so you can flip a switch and
recompile to work with a plain std::string (8-bit chars). [more deleted]
If we decide to do something different with strings, I am in
favor of dumping DOMString entirely and going with an already
existing, reasonably standard and well supported string.
Something that we don't need to maintain ourselves, teach people
about, etc.
How to best do memory management will need some thought. The strings
for tagnames, and attribute names and values want to be shared
as they tend to appear repeatedly in some documents. So some
sort of reference counting will probably be needed.
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.
-- Andy
