3) Now that we're floating XMLCh to be wchar_t, most uses of the const
char* ctor are eliminated. But if we take it out now the following code
will fail:
AttrImpl.cpp(210)
AttrImpl.cpp(212)
DStringPool.cpp(178)
NodeImpl.cpp(146)
NodeImpl.cpp(668)
NodeImpl.cpp(728)
NodeImpl.cpp(729)
NodeImpl.cpp(730)
NodeImpl.cpp(771)
NodeImpl.cpp(772)
NodeImpl.cpp(773)
NodeImpl.cpp(774)
All of these are string literals and with the proper use of the XMLStrL()
macro transcoding could be avoided (on most platforms). The only exception
is in DStringPool::getStaticString(), but I'm pretty sure we can change the
prototype to take XMLCh* rather than char*.
I'm inclined to eliminate the const char* ctor and make it either a global
transcode() function or perhaps a static member in DOMString. Thoughts?
As for the other points, yes, let's use the standard names for these.
-Rob
Curt Arnold wrote:
3) I'd vote for non-member transcoding utility. This was an issue when I
did my experiment with changing DOMString to have a subset of
std::basic_string<XMLCh> semantics. Sample code was doing something like
DOMString a("A");
Where a std::basic_string constructor was lost with the char* to XMLCh*
conversion. However, taking out to char* constructor will break some code
(but probably mostly code that should be broken).
4) I'd vote for reserve since it parallels std::basic_string
5) I don't have my std lib documentation handy, but I think it is erase in
std::basic_string.
I'd also add an empty() (ala basic_string) method that is used to determine
if the string is empty.
