Document object model

Date: Tue, 18 Nov 2014 09:30:19 -0800 Subject: docs: Regenerated documentation Also fix documentation jam rules for Windows. --- docs/manual/dom.html | 196 ++++++++++++++++++++++++++------------------------- 1 file changed, 100 insertions(+), 96 deletions(-) (limited to 'docs/manual/dom.html') diff --git a/docs/manual/dom.html b/docs/manual/dom.html index 57d3ea0..3d7cd29 100644 --- a/docs/manual/dom.html +++ b/docs/manual/dom.html @@ -4,15 +4,15 @@ Document object model - - + +

-pugixml 1.4 manual | +pugixml 1.5 manual | Overview | Installation | Document: @@ -28,20 +28,20 @@

-Document object model + Document object model

@@ -56,7 +56,7 @@

-Tree structure + Tree structure

The XML document is represented with a tree data structure. The root of the @@ -66,9 +66,9 @@ which correspond to C++ type xml_attribute, and some additional data (i.e. name).

- The tree nodes can be of one of the following - types (which together form the enumeration xml_node_type): +

+ The tree nodes can be of one of the following types (which together form + the enumeration xml_node_type):

@@ -81,6 +81,7 @@ several ways, which are covered below. There can be only one document node in the tree; document node does not have any XML representation.

+
Element/tag node (node_element) - this @@ -188,7 +189,7 @@ (its parent should be the document). The example XML representation of a document type declaration node is as follows:

<!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]>
+<!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]>
 
 
           Here the node has value "greeting [ <!ELEMENT
@@ -208,6 +209,7 @@

<?xml version="1.0"?>
 <mesh name="mesh_root">
@@ -235,7 +237,7 @@
 
 
 
-C++ interface
+ C++ interface
 
 
@@ -259,18 +261,21 @@
         some operations on xml_node
         are only valid for certain node types. The classes are described below.
       
-
-        xml_document is the owner of the entire
-        document structure; it is a non-copyable class. The interface of xml_document consists of loading functions
-        (see Loading document), saving functions (see Saving document) and the entire
-        interface of xml_node, which
-        allows for document inspection and/or modification. Note that while xml_document is a sub-class of xml_node, xml_node
-        is not a polymorphic type; the inheritance is present only to simplify usage.
-        Alternatively you can use the document_element
-        function to get the element node that's the immediate child of the document.
+

+        xml_document is the owner
+        of the entire document structure; it is a non-copyable class. The interface
+        of xml_document consists
+        of loading functions (see  Loading document), saving functions (see  Saving document)
+        and the entire interface of xml_node,
+        which allows for document inspection and/or modification. Note that while
+        xml_document is a sub-class
+        of xml_node, xml_node is not a polymorphic type; the
+        inheritance is present only to simplify usage. Alternatively you can use
+        the document_element function
+        to get the element node that's the immediate child of the document.
       
-
-        Default constructor of xml_document
+

+        Default constructor of xml_document
         initializes the document to the tree with only a root node (document node).
         You can then populate it with data using either tree modification functions
         or loading functions; all loading functions destroy the previous tree with
@@ -295,12 +300,12 @@
           are destroyed.
         

 
 
-
-        xml_node
-        is the handle to document node; it can point to any node in the document,
-        including the document node itself. There is a common interface for nodes
-        of all types; the actual node type can
-        be queried via the xml_node::type() method. Note that xml_node
+

+        xml_node is the handle to
+        document node; it can point to any node in the document, including the document
+        node itself. There is a common interface for nodes of all types; the actual
+        node type can be queried via the xml_node::type()
+        method. Note that xml_node
         is only a handle to the actual node, not the node itself - you can have several
         xml_node handles pointing
         to the same underlying object. Destroying xml_node
@@ -310,8 +315,8 @@
         a pointer; you can safely pass or return xml_node
         objects by value without additional overhead.
       
-
-        There is a special value of xml_node
+

+        There is a special value of xml_node
         type, known as null node or empty node (such nodes have type node_null). It does not correspond to any
         node in any document, and thus resembles null pointer. However, all operations
         are defined on empty nodes; generally the operations don't do anything and
@@ -321,40 +326,37 @@
         have a parent, the first parent() call returns null node; the second parent()
         call then also returns null node, which makes error handling easier.
       
-
-        xml_attribute
-        is the handle to an XML attribute; it has the same semantics as xml_node, i.e. there can be several xml_attribute handles pointing to the same
-        underlying object and there is a special null attribute value, which propagates
-        to function results.
+

+        xml_attribute is the handle
+        to an XML attribute; it has the same semantics as xml_node,
+        i.e. there can be several xml_attribute
+        handles pointing to the same underlying object and there is a special null
+        attribute value, which propagates to function results.
       
-
-        Both xml_node and xml_attribute
-        have the default constructor which initializes them to null objects.
+

+        Both xml_node and xml_attribute have the default constructor
+        which initializes them to null objects.
       
-
-        xml_node and xml_attribute
-        try to behave like pointers, that is, they can be compared with other objects
-        of the same type, making it possible to use them as keys in associative containers.
-        All handles to the same underlying object are equal, and any two handles
-        to different underlying objects are not equal. Null handles only compare
-        as equal to themselves. The result of relational comparison can not be reliably
-        determined from the order of nodes in file or in any other way. Do not use
-        relational comparison operators except for search optimization (i.e. associative
-        container keys).
+

+        xml_node and xml_attribute try to behave like pointers,
+        that is, they can be compared with other objects of the same type, making
+        it possible to use them as keys in associative containers. All handles to
+        the same underlying object are equal, and any two handles to different underlying
+        objects are not equal. Null handles only compare as equal to themselves.
+        The result of relational comparison can not be reliably determined from the
+        order of nodes in file or in any other way. Do not use relational comparison
+        operators except for search optimization (i.e. associative container keys).
       
-
-        If
-        you want to use xml_node
+

+        If you want to use xml_node
         or xml_attribute objects
         as keys in hash-based associative containers, you can use the hash_value member functions. They return
         the hash values that are guaranteed to be the same for all handles to the
         same underlying object. The hash value for null handles is 0.
       
-
-        Finally handles
-        can be implicitly cast to boolean-like objects, so that you can test if the
-        node/attribute is empty with the following code: if
-        (node) { ...
+

+        Finally handles can be implicitly cast to boolean-like objects, so that you
+        can test if the node/attribute is empty with the following code: if (node) { ...
         } or if
         (!node) { ...
         } else { ... }.
@@ -377,14 +379,14 @@
 

 
 
-Unicode interface
+ Unicode interface
 
 
         There are two choices of interface and internal representation when configuring
         pugixml: you can either choose the UTF-8 (also called char) interface or
         UTF-16/32 (also called wchar_t) one. The choice is controlled via PUGIXML_WCHAR_MODE
         define; you can set it via pugiconfig.hpp or via preprocessor options, as
-        discussed in Additional configuration
+        discussed in  Additional configuration
         options. If this define is set, the wchar_t
         interface is used; otherwise (by default) the char interface is used. The
         exact wide character encoding is assumed to be either UTF-16 or UTF-32 and
@@ -416,13 +418,13 @@
 
const wchar_t* xml_node::name() const;
 bool xml_node::set_name(const wchar_t* value);
 
-
-        There is a special type, pugi::char_t, that is defined as the character
-        type and depends on the library configuration; it will be also used in the
-        documentation hereafter. There is also a type pugi::string_t,
-        which is defined as the STL string of the character type; it corresponds
-        to std::string in char mode and to std::wstring
-        in wchar_t mode.
+

+        There is a special type, pugi::char_t,
+        that is defined as the character type and depends on the library configuration;
+        it will be also used in the documentation hereafter. There is also a type
+        pugi::string_t, which is defined as the STL string
+        of the character type; it corresponds to std::string
+        in char mode and to std::wstring in wchar_t mode.
       
 
         In addition to the interface, the internal implementation changes to store
@@ -434,10 +436,9 @@
         inconvenient to process and most of your XML data is non-ASCII, wchar_t mode
         is probably a better choice.
       
-
-        There are cases when you'll have
-        to convert string data between UTF-8 and wchar_t encodings; the following
-        helper functions are provided for such purposes:
+

+        There are cases when you'll have to convert string data between UTF-8 and
+        wchar_t encodings; the following helper functions are provided for such purposes:
       
 std::string as_utf8(const wchar_t* str);
 std::wstring as_wide(const char* str);
@@ -484,7 +485,7 @@
 
 
 
-Thread-safety guarantees
+ Thread-safety guarantees
 
 
         Almost all functions in pugixml have the following thread-safety guarantees:
@@ -510,13 +511,13 @@
 

         The only exception is set_memory_management_functions;
         it modifies global variables and as such is not thread-safe. Its usage policy
-        has more restrictions, see Custom memory allocation/deallocation
+        has more restrictions, see  Custom memory allocation/deallocation
         functions.
       
 
 
 
-Exception guarantees
+ Exception guarantees
 
 
         With the exception of XPath, pugixml itself does not throw any exceptions.
@@ -540,7 +541,7 @@
 
 
 
-Memory management
+ Memory management
 
 
         pugixml requests the memory needed for document storage in big chunks, and
@@ -549,22 +550,21 @@
       
 
 
-Custom memory allocation/deallocation
+ Custom memory allocation/deallocation
         functions
 
-
-          All
-          memory for tree structure, tree data and XPath objects is allocated via
-          globally specified functions, which default to malloc/free. You can set
-          your own allocation functions with set_memory_management function. The
-          function interfaces are the same as that of malloc/free:
+

+          All memory for tree structure, tree data and XPath objects is allocated
+          via globally specified functions, which default to malloc/free. You can
+          set your own allocation functions with set_memory_management function.
+          The function interfaces are the same as that of malloc/free:
         
 typedef void* (*allocation_function)(size_t size);
 typedef void (*deallocation_function)(void* ptr);
 
-
-          You can use the following accessor
-          functions to change or get current memory management functions:
+

+          You can use the following accessor functions to change or get current memory
+          management functions:
         
 void set_memory_management_functions(allocation_function allocate, deallocation_function deallocate);
 allocation_function get_memory_allocation_function();
@@ -589,6 +589,7 @@
           This is a simple example of custom memory management (samples/custom_memory_management.cpp):
         
 
+          
 
 void* custom_allocate(size_t size)
 {
@@ -603,6 +604,7 @@
 
         
 
+          
 
 pugi::set_memory_management_functions(custom_allocate, custom_deallocate);
 
@@ -617,7 +619,7 @@
 
 
 
-Memory consumption tuning
+ Memory consumption tuning
 
 
           There are several important buffering optimizations in pugixml that rely
@@ -629,7 +631,7 @@
         
 
           These constants can be tuned via configuration defines, as discussed in
-          Additional configuration
+           Additional configuration
         options; it is recommended to set them in pugiconfig.hpp.
         
 
@@ -640,6 +642,7 @@
               is 32 Kb; for some applications the size is too large (i.e. embedded
               systems with little heap space or applications that keep lots of XML
               documents in memory). A minimum size of 1 Kb is recommended. 


+
             
 
               PUGIXML_MEMORY_OUTPUT_STACK
@@ -649,6 +652,7 @@
               using node output from threads with little stack space, decreasing
               this value can prevent stack overflows. A minimum size of 1 Kb is recommended.
               


+
             
 
               PUGIXML_MEMORY_XPATH_PAGE_SIZE
@@ -663,7 +667,7 @@
 
 
 
-Document memory management
+ Document memory management
         internals
 
 
@@ -673,7 +677,7 @@
         
 
           When the document is loaded from file/buffer, unless an inplace loading
-          function is used (see Loading document from memory), a complete copy of character
+          function is used (see  Loading document from memory), a complete copy of character
           stream is made; all names/values of nodes and attributes are allocated
           in this buffer. This buffer is allocated via a single large allocation
           and is only freed when document memory is reclaimed (i.e. if the xml_document object is destroyed or if another
@@ -711,7 +715,7 @@
 

 
 
-pugixml 1.4 manual |
+pugixml 1.5 manual |
 		Overview |
 		Installation |
 		Document:
-- 
cgit v1.2.3

-Document object model + Document object model

-Tree structure + Tree structure

-C++ interface + C++ interface

-Unicode interface + Unicode interface

-Thread-safety guarantees + Thread-safety guarantees

-Exception guarantees + Exception guarantees

-Memory management + Memory management

-Custom memory allocation/deallocation + Custom memory allocation/deallocation functions

-Memory consumption tuning + Memory consumption tuning

-Document memory management + Document memory management internals