On Mon, Jun 24, 2002 at 12:03:03AM -0400, Luca Padovani wrote: > > DOMString lacks a constructor, and assignment operator that reads a > > std::string value, and an assignment operation for std::string that > > reads a DOMString value. It is not essential, but it would be greatly > > appreciated. > and it wouldn't be difficult at all. The only thing I'm concerned about is > that using std::string inside DOMString.hh will cause the inclusion of a > not-so-small .h file of the standard library into many DOM files, and > consequently many user files. No, you can avoid it: just use a forward declaration like this: namespace std { class string; }; And you should do fine #including <string> only in non-header sources. Uhm... no, you cannot, since string is a damn typedef. Uhm... is there a way to forward declare a typedef? After all, if you just use references, the compiler has no use of knowing the structure size when compiling the headers... > The alternative possibility is to have helper functions (say in > DOMStringAux), but they wouldn't be as natural as a constructor and an > assignment operator. I quite agree... [double adding a node fails silently] > I suspect it might be a gdome2 bug. I would suggest to write the smallest > gdome2 program reproducing the problem, and posting the source on the > mailing list. Attached as test1.tar.gz > [snip, about utf-8 encodings] > Again, a small .xml file and a complete (small!) program with the problem > woule be a great help. It might be a problem in the conversion > UTF-8/UTF-16 done by gmetadom, or a low-level problem in libxml2, but I > think the latter is less likely (libxml2 is quite well tested). I tried to reproduce this with a program that just reads and saves an XML file, but I had no luck. I saw that Galeon stores accented chars like this: <title>Università</title> ...and gdome2 rewrites it like this: <title>Università</title> But this is not bad and I didn't get that warning. Umpf. I never alter strings in the main application, I just move and copy elements around. Tomorrow I'll try and do some more investigations... It would help me to know in what cases the libxml2 warning I've reported gets printed; the warning was: "xmlEncodeEntitiesReentrant : char out of range". Another curious note: when that error is given, the DOM tree is saved in what seems to be latin1: accented chars are iso-latin1 accented chars and other accented elements are as other binary data. This seems to be why libxml2 or libgdome2 complain when reloading those saved files. Thanks! Bye, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico debian org>
Attachment:
test1.tar.gz
Description: Binary data