I think that I had to fix all of these in my "lets try basic_string semantics" experiment by using array initialization. I can send you that code and you can mine it just for replacement of the the const char* constructors.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, January 31, 2000 12:48 PM To: [EMAIL PROTECTED] Subject: RE: DOMString (was: xalan-c Problem with Xerces initialization) 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.
