Xerces-c++ DOM Programming Guide (i) __linux

Original address: http://xerces.apache.org/xerces-c/program-dom.html

Design Objectives
The C + + implementation of the DOM is based on the Apache recommended Dom (Apache recommended DOM C + + binding).
The objectives are designed to meet the following requirements:
1. Reduce the memory occupancy rate.
2. Improve application performance, especially for server types and multi-threaded applications.
3. Excellent ductility in multiple processing systems.
4. Compared to Java, its style is more like C + +

Xerces-c++ support for DOM level 3
xerces-c++2.8.0 contains a partial implementation of level 3 of the Consortium DOM (Document Object model), which is experimental. For more information, see the document DOM Level 3 Support.

Using the DOM API
Accessing the API in your program code
#include <xercesc/dom/DOM.hpp>
In header file <dom/DOM.hpp>, contains all the header files required by the DOM API class

Class name
Dom class names are prefixed with "Dom" (if the class name itself does not begin with "Dom"), for example, "Domnode" to prevent the DOM class name from being confused with some class names: Some names may already be used in classes that an application or a DOM-based application must link to.
domdocument* myDocument;
domnode* Anode;
domtext* Sometext;

Object Management
The application uses standard C + + pointers to directly access the nodes implemented by the object in the C + + DOM.
Consider the following code snippet:
domnode* Anode;
domnode* Docrootnode;
Anode = Somedocument->createelement (anelementname);
Docrootnode = Somedocument->getdocumentelement ();
Docrootnode->appendchild (anode);

Memory management
The implementation of the C + + DOM provides a release () method for releasing all the orphan (that is, now no longer used) resource created by the Creatxxx factory method, and the memory resources freed by object destruction are managed by the implementation of the C + + DOM. For more information, check out the Apache recommended DOM C + + binding.

Creating objects using Domimplementation::createxxx
The user must invoke the release () function to free the objects created by domimplementation::createxxx that have now been used, such as Dombuilder, Domwriter, DOMDocument, Domdocumenttype.
Attempting to access an object that has been disposed will cause an exception behavior.
1. When a DOMDocument object is freed, all child objects associated with this object and the objects it owns (such as Domrange, Domtreewalker, domnodeiterator, or any orphaned nodes) are also freed.
2. When a DOMDocument object is replicated, the copied document object is no longer associated with its parent class document (original master documents) and the release to display.
3. When a domdocumenttype is inserted into a domdocument, the Domdocumenttype also has a host (owner), which is automatically released when its host (owner document) is released, A Domexception::invalid_access_err exception is generated if the node is released at this time.

Creating objects using Domdocument::createxxx
The user should call the release () function to display any orphaned nodes. When an orphaned node is freed, its associated child nodes are also freed. Accessing a freed node will result in abnormal behavior. Those orphaned nodes will eventually be released, and if they are not released, they will be released when their host (owner document) is released.
Attempting to release a node with a father will result in a Domexception::invalid_access_err exception.

Create objects using Domdocumentrange::createrange or domdocumenttraversal::createxxx
     when Domrange, Domnodeiterator, the user should call the release () function when the Domtreewalker is finished using. Accessing a Freed object will result in an exception behavior. Those objects will eventually be released, and if they are not released, they will be released when their host (owner document) is released. The
has one example:
   //
   //  Create A small document tree
    //
    {
        xmlch tempstr[100];

Xmlstring::transcode ("Range", TempStr, 99);
domimplementation* Impl = domimplementationregistry::getdomimplementation (tempstr, 0);

Xmlstring::transcode ("Root", TEMPSTR, 99);
domdocument* doc = impl->createdocument (0, tempstr, 0);
domelement* root = Doc->getdocumentelement ();

Xmlstring::transcode ("Firstelement", TempStr, 99);
domelement* e1 = doc->createelement (TEMPSTR);
Root->appendchild (E1);

Xmlstring::transcode ("Secondelement", TempStr, 99);
domelement* e2 = doc->createelement (TEMPSTR);
Root->appendchild (E2);

Xmlstring::transcode ("Atextnode", TempStr, 99);
domtext* Textnode = Doc->createtextnode (TEMPSTR);
E1->appendchild (Textnode);

Optionally, call Release () to release the resource associated with the range
domrange* range = Doc->createrange ();
Range->release ();

Removedelement is a orphaned node, optionally call release () to release associated resource
domelement* removedelement = root->removechild (E2);
Removedelement->release ();

No need to release this returned object which be owned by implementation
Xmlstring::transcode ("*", TEMPSTR, 99);
domnodelist* nodelist = Doc->getelementsbytagname (TEMPSTR);

Done with the document, must call Release () to release the entire document resources
Doc->release ();
};

String type
The C + + DOM uses a plain, Xmlch * UTF-16 string as a string type, and these (xmlch*) utf-16 type strings are extremely inexpensive.
C + + DOM
Const xmlch* NodeValue = Anode->getnodevalue ();
All string data will be saved in memory until the document object is destroyed. However, as these string data are likely to be recycled as necessary in the execution process (recycled), the user should use the appropriate copy of the return string as a type-safe reference.
For example, when a Domnode is released, the memory resources allocated to it are recycled.

Xmlch xfoo[] = {chlatin_f, chlatin_o, Chlatin_o, chnull};

PATTR has node value = "Foo"
Fnodevalue has "foo"
Pattr->setnodevalue (Xfoo);
Const xmlch* Fnodevalue = Pattr->getnodevalue ();

Fnodevalue has "foo"
Make a copy of the string for future reference
xmlch* Oldnodevalue = xmlstring::replicate (Fnodevalue);

Release the node pattr
Pattr->release ()

Other operations

Implementation may have recycled the memory of the pattr already
So it's not safe to expect Fnodevalue still have "foo"
if (xmlstring::comparestring (Xfoo, Fnodevalue))
printf ("Fnodevalue has some other content/n");

Should use your own safe copy
if (! Xmlstring::comparestring (Xfoo, Oldnodevalue))
printf ("Use your own copy of the Oldnodevalue if want to reference the string later/n");

Delete your own replicated string when done
Xmlstring::release (&oldnodevalue);

If you call Domnode::setnodevalue () to set a new node value, the execution is simply an area of memory occupied by the overriding node value, so the previous pointer will now automatically point to the new value. The user should use the appropriate copy of the string previously returned as a type-safe reference. For example:
Xmlch xfoo[] = {chlatin_f, chlatin_o, Chlatin_o, chnull};
Xmlch xfee[] = {chlatin_f, chlatin_e, Chlatin_e, chnull};

PATTR has node value = "Foo"
Pattr->setnodevalue (Xfoo);
Const xmlch* Fnodevalue = Pattr->getnodevalue ();

Fnodevalue has "foo"
Make a copy of the string for future reference
xmlch* Oldnodevalue = xmlstring::replicate (Fnodevalue);

Now set pattr with a new node value "fee"
Pattr->setnodevalue (Xfee);

Should not rely on Fnodevalue for the "old" node value, it may not compare
if (xmlstring::comparestring (Xfoo, Fnodevalue))
printf ("Should not rely on fnodevalue for the old Node value/n");

Should use your own safe copy
if (! Xmlstring::comparestring (Xfoo, Oldnodevalue))
printf ("Use your own copy of the Oldnodevalue if want to reference the string later/n");

Delete your own replicated string when done
Xmlstring::release (&oldnodevalue);

This is done when we call Domnode::setnodevalue () Hundreds of times to prevent memory consumption from becoming geometric growth. This design allows the user to actively choose whether the returned string should be left in memory manually or copied to the application's own stack. (This is the original version of this design allows users to actively select which returned string should stay in memory by manually copying the Stri Ng to application ' s own heap. There are some questions, the question is my own understanding.