RapidXML is a fast, lightweight C++ XML DOM Parser, but it has some quirks.
The worst of these to my mind is this:
3.2 Ownership Of Strings.
Nodes and attributes produced by RapidXml do not
own their name and value strings. They
merely hold the pointers to them. This
means you have to be careful when
setting these values manually, by
usingxml_base::name(const Ch *)or
xml_base::value(const Ch *)functions.Care must be taken to ensure that
lifetime of the string passed is at
least as long as lifetime of the
node/attribute. The easiest way to
achieve it is to allocate the string
from memory_pool owned by the
document. Use
memory_pool::allocate_string()
function for this purpose.
Now, I understand it’s done this way for speed, but this feels like an car crash waiting to happen. The following code looks innocuous but ‘name’ and ‘value’ are out of scope when foo returns, so the doc is undefined.
void foo()
{
char name[]="Name";
char value[]="Value";
doc.append_node(doc.allocate_node(node_element, name, value));
}
The suggestion of using allocate_string() as per manual works, but it’s so easy to forget.
Has anyone ‘enhanced’ RapidXML to avoid this issue?
I don’t use RapidXML, but maybe my approach can solve your problem.
I started using Xerces, but I found it heavy, besides other minor annoyances, so I moved to CPPDOM. When I made the move I decided to create a set of wrapper classes, so that my code wouldn’t be dependent from the specific XML ‘engine’ and I could port to another if needed.
I created my own classes to represent the basic DOM entities (node, document, etc). Those classes use internally the pimpl idiom to use CPPDOM objects.
Since my node object contains the ‘real’ node object (from CPPDOM) I can manage anything as needed, so proper allocation and deallocation of strings wouldn’t be a problem there.
Since my code is for CPPDOM, I don’t think it would be much useful for you, but I can post it if you want.
BTW, if you already have too much code that already uses RapidXML you can reproduce its interfaces in your wrapper classes. I didn’t do it because the code that used Xerces was not that long and I’d have to rewrite it anyway.