Skip to content
Snippets Groups Projects
manual.html 530 KiB
Newer Older
1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000
</li>
<li>
<p>Apple MacOSX (GCC 4.0.1 x86/x64/PowerPC, Clang 3.5 x64)</p>
</li>
<li>
<p>Sun Solaris (sunCC x86/x64)</p>
</li>
<li>
<p>Microsoft Xbox 360</p>
</li>
<li>
<p>Nintendo Wii (Metrowerks CodeWarrior 4.1)</p>
</li>
<li>
<p>Sony Playstation Portable (GCC 3.4.2)</p>
</li>
<li>
<p>Sony Playstation 3 (GCC 4.1.1, SNC 310.1)</p>
</li>
<li>
<p>Various portable platforms (Android NDK, BlackBerry NDK, Samsung bada, Windows CE)</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="dom"><a class="anchor" href="#dom"></a>3. Document object model</h2>
<div class="sectionbody">
<div class="paragraph">
<p>pugixml stores XML data in DOM-like way: the entire XML document (both document structure and element data) is stored in memory as a tree. The tree can be loaded from a character stream (file, string, C&#43;&#43; I/O stream), then traversed with the special API or XPath expressions. The whole tree is mutable: both node structure and node/attribute data can be changed at any time. Finally, the result of document transformations can be saved to a character stream (file, C&#43;&#43; I/O stream or custom transport).</p>
</div>
<div class="sect2">
<h3 id="dom.tree"><a class="anchor" href="#dom.tree"></a>3.1. Tree structure</h3>
<div class="paragraph">
<p>The XML document is represented with a tree data structure. The root of the tree is the document itself, which corresponds to C&#43;&#43; type <a href="#xml_document">xml_document</a>. Document has one or more child nodes, which correspond to C&#43;&#43; type <a href="#xml_node">xml_node</a>. Nodes have different types; depending on a type, a node can have a collection of child nodes, a collection of attributes, which correspond to C&#43;&#43; type <a href="#xml_attribute">xml_attribute</a>, and some additional data (i.e. name).</p>
</div>
<div id="xml_node_type" class="paragraph">
<p>The tree nodes can be of one of the following types (which together form the enumeration <code>xml_node_type</code>):</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Document node (<a id="node_document"></a><code>node_document</code>) - this is the root of the tree, which consists of several child nodes. This node corresponds to <a href="#xml_document">xml_document</a> class; note that <a href="#xml_document">xml_document</a> is a sub-class of <a href="#xml_node">xml_node</a>, so the entire node interface is also available. However, document node is special in several ways, which are covered below. There can be only one document node in the tree; document node does not have any XML representation.</p>
</li>
<li>
<p>Element/tag node (<a id="node_element"></a><code>node_element</code>) - this is the most common type of node, which represents XML elements. Element nodes have a name, a collection of attributes and a collection of child nodes (both of which may be empty). The attribute is a simple name/value pair. The example XML representation of element nodes is as follows:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;node attr="value"&gt;&lt;child/&gt;&lt;/node&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>There are two element nodes here: one has name <code>"node"</code>, single attribute <code>"attr"</code> and single child <code>"child"</code>, another has name <code>"child"</code> and does not have any attributes or child nodes.</p>
</div>
</li>
<li>
<p>Plain character data nodes (<a id="node_pcdata"></a><code>node_pcdata</code>) represent plain text in XML. PCDATA nodes have a value, but do not have a name or children/attributes. Note that <strong>plain character data is not a part of the element node but instead has its own node</strong>; an element node can have several child PCDATA nodes. The example XML representation of text nodes is as follows:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;node&gt; text1 &lt;child/&gt; text2 &lt;/node&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>Here <code>"node"</code> element has three children, two of which are PCDATA nodes with values <code>" text1 "</code> and <code>" text2 "</code>.</p>
</div>
</li>
<li>
<p>Character data nodes (<a id="node_cdata"></a><code>node_cdata</code>) represent text in XML that is quoted in a special way. CDATA nodes do not differ from PCDATA nodes except in XML representation - the above text example looks like this with CDATA:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;node&gt; &lt;![CDATA[[text1]]&gt; &lt;child/&gt; &lt;![CDATA[[text2]]&gt; &lt;/node&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>CDATA nodes make it easy to include non-escaped <code>&lt;</code>, <code>&amp;</code> and <code>&gt;</code> characters in plain text. CDATA value can not contain the character sequence <code>]]&gt;</code>, since it is used to determine the end of node contents.</p>
</div>
</li>
<li>
<p>Comment nodes (<a id="node_comment"></a><code>node_comment</code>) represent comments in XML. Comment nodes have a value, but do not have a name or children/attributes. The example XML representation of a comment node is as follows:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;!-- comment text --&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>Here the comment node has value <code>"comment text"</code>. By default comment nodes are treated as non-essential part of XML markup and are not loaded during XML parsing. You can override this behavior with <a href="#parse_comments">parse_comments</a> flag.</p>
</div>
</li>
<li>
<p>Processing instruction node (<a id="node_pi"></a><code>node_pi</code>) represent processing instructions (PI) in XML. PI nodes have a name and an optional value, but do not have children/attributes. The example XML representation of a PI node is as follows:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;?name value?&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>Here the name (also called PI target) is <code>"name"</code>, and the value is <code>"value"</code>. By default PI nodes are treated as non-essential part of XML markup and are not loaded during XML parsing. You can override this behavior with <a href="#parse_pi">parse_pi</a> flag.</p>
</div>
</li>
<li>
<p>Declaration node (<a id="node_declaration"></a><code>node_declaration</code>) represents document declarations in XML. Declaration nodes have a name (<code>"xml"</code>) and an optional collection of attributes, but do not have value or children. There can be only one declaration node in a document; moreover, it should be the topmost node (its parent should be the document). The example XML representation of a declaration node is as follows:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;?xml version="1.0"?&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>Here the node has name <code>"xml"</code> and a single attribute with name <code>"version"</code> and value <code>"1.0"</code>. By default declaration nodes are treated as non-essential part of XML markup and are not loaded during XML parsing. You can override this behavior with <a href="#parse_declaration">parse_declaration</a> flag. Also, by default a dummy declaration is output when XML document is saved unless there is already a declaration in the document; you can disable this with <a href="#format_no_declaration">format_no_declaration</a> flag.</p>
</div>
</li>
<li>
<p>Document type declaration node (<a id="node_doctype"></a><code>node_doctype</code>) represents document type declarations in XML. Document type declaration nodes have a value, which corresponds to the entire document type contents; no additional nodes are created for inner elements like <code>&lt;!ENTITY&gt;</code>. There can be only one document type declaration node in a document; moreover, it should be the topmost node (its parent should be the document). The example XML representation of a document type declaration node is as follows:</p>
<div class="listingblock">
<div class="content">
<pre>&lt;!DOCTYPE greeting [ &lt;!ELEMENT greeting (#PCDATA)&gt; ]&gt;</pre>
</div>
</div>
<div class="paragraph">
<p>Here the node has value <code>"greeting [ &lt;!ELEMENT greeting (#PCDATA)&gt; ]"</code>. By default document type declaration nodes are treated as non-essential part of XML markup and are not loaded during XML parsing. You can override this behavior with <a href="#parse_doctype">parse_doctype</a> flag.</p>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>Finally, here is a complete example of XML document and the corresponding tree representation (<a href="samples/tree.xml" class="bare">samples/tree.xml</a>):</p>
</div>
<table class="tableblock frame-none grid-all spread">
<colgroup>
<col style="width: 50%;">
<col style="width: 50%;">
</colgroup>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><div><div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="xml"><span class="tok-cp">&lt;?xml version=&quot;1.0&quot;?&gt;</span>
<span class="tok-nt">&lt;mesh</span> <span class="tok-na">name=</span><span class="tok-s">&quot;mesh_root&quot;</span><span class="tok-nt">&gt;</span>
    <span class="tok-c">&lt;!-- here is a mesh node --&gt;</span>
    some text
    <span class="tok-cp">&lt;![CDATA[someothertext]]&gt;</span>
    some more text
    <span class="tok-nt">&lt;node</span> <span class="tok-na">attr1=</span><span class="tok-s">&quot;value1&quot;</span> <span class="tok-na">attr2=</span><span class="tok-s">&quot;value2&quot;</span> <span class="tok-nt">/&gt;</span>
    <span class="tok-nt">&lt;node</span> <span class="tok-na">attr1=</span><span class="tok-s">&quot;value2&quot;</span><span class="tok-nt">&gt;</span>
        <span class="tok-nt">&lt;innernode/&gt;</span>
    <span class="tok-nt">&lt;/node&gt;</span>
<span class="tok-nt">&lt;/mesh&gt;</span>
<span class="tok-cp">&lt;?include somedata?&gt;</span></code></pre>
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><div><div class="imageblock">
<div class="content">
<a class="image" href="images/dom_tree.png"><img src="images/dom_tree.png" alt="dom tree"></a>
</div>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect2">
<h3 id="dom.cpp"><a class="anchor" href="#dom.cpp"></a>3.2. C&#43;&#43; interface</h3>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
All pugixml classes and functions are located in the <code>pugi</code> namespace; you have to either use explicit name qualification (i.e. <code>pugi::xml_node</code>), or to gain access to relevant symbols via <code>using</code> directive (i.e. <code>using pugi::xml_node;</code> or <code>using namespace pugi;</code>). The namespace will be omitted from all declarations in this documentation hereafter; all code examples will use fully qualified names.
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p>Despite the fact that there are several node types, there are only three C&#43;&#43; classes representing the tree (<code>xml_document</code>, <code>xml_node</code>, <code>xml_attribute</code>); some operations on <code>xml_node</code> are only valid for certain node types. The classes are described below.</p>
</div>
<div class="paragraph">
<p><a id="xml_document"></a><a id="xml_document::document_element"></a>
<code>xml_document</code> is the owner of the entire document structure; it is a non-copyable class. The interface of <code>xml_document</code> consists of loading functions (see <a href="#loading">Loading document</a>), saving functions (see <a href="#saving">Saving document</a>) and the entire interface of <code>xml_node</code>, which allows for document inspection and/or modification. Note that while <code>xml_document</code> is a sub-class of <code>xml_node</code>, <code>xml_node</code> is not a polymorphic type; the inheritance is present only to simplify usage. Alternatively you can use the <code>document_element</code> function to get the element node that&#8217;s the immediate child of the document.</p>
</div>
<div class="paragraph">
<p><a id="xml_document::ctor"></a><a id="xml_document::dtor"></a><a id="xml_document::reset"></a>
Default constructor of <code>xml_document</code> 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 all occupied memory, which puts existing node/attribute handles for this document to invalid state. If you want to destroy the previous tree, you can use the <code>xml_document::reset</code> function; it destroys the tree and replaces it with either an empty one or a copy of the specified document. Destructor of <code>xml_document</code> also destroys the tree, thus the lifetime of the document object should exceed the lifetimes of any node/attribute handles that point to the tree.</p>
</div>
<div class="admonitionblock caution">
<table>
<tr>
<td class="icon">
<div class="title">Caution</div>
</td>
<td class="content">
While technically node/attribute handles can be alive when the tree they&#8217;re referring to is destroyed, calling any member function for these handles results in undefined behavior. Thus it is recommended to make sure that the document is destroyed only after all references to its nodes/attributes are destroyed.
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p><a id="xml_node"></a><a id="xml_node::type"></a>
<code>xml_node</code> 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 <a href="#xml_node_type">node type</a> can be queried via the <code>xml_node::type()</code> method. Note that <code>xml_node</code> is only a handle to the actual node, not the node itself - you can have several <code>xml_node</code> handles pointing to the same underlying object. Destroying <code>xml_node</code> handle does not destroy the node and does not remove it from the tree. The size of <code>xml_node</code> is equal to that of a pointer, so it is nothing more than a lightweight wrapper around a pointer; you can safely pass or return <code>xml_node</code> objects by value without additional overhead.</p>
</div>
<div id="node_null" class="paragraph">
<p>There is a special value of <code>xml_node</code> type, known as null node or empty node (such nodes have type <code>node_null</code>). 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&#8217;t do anything and return empty nodes/attributes or empty strings as their result (see documentation for specific functions for more detailed information). This is useful for chaining calls; i.e. you can get the grandparent of a node like so: <code>node.parent().parent()</code>; if a node is a null node or it does not have a parent, the first <code>parent()</code> call returns null node; the second <code>parent()</code> call then also returns null node, which makes error handling easier.</p>
</div>
<div id="xml_attribute" class="paragraph">
<p><code>xml_attribute</code> is the handle to an XML attribute; it has the same semantics as <code>xml_node</code>, i.e. there can be several <code>xml_attribute</code> handles pointing to the same underlying object and there is a special null attribute value, which propagates to function results.</p>
</div>
<div class="paragraph">
<p><a id="xml_attribute::ctor"></a><a id="xml_node::ctor"></a>
Both <code>xml_node</code> and <code>xml_attribute</code> have the default constructor which initializes them to null objects.</p>
</div>
<div class="paragraph">
<p><a id="xml_attribute::comparison"></a><a id="xml_node::comparison"></a>
<code>xml_node</code> and <code>xml_attribute</code> 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).</p>
</div>
<div class="paragraph">
<p><a id="xml_attribute::hash_value"></a><a id="xml_node::hash_value"></a>
If you want to use <code>xml_node</code> or <code>xml_attribute</code> objects as keys in hash-based associative containers, you can use the <code>hash_value</code> 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.</p>
</div>
<div class="paragraph">
<p><a id="xml_attribute::unspecified_bool_type"></a><a id="xml_node::unspecified_bool_type"></a><a id="xml_attribute::empty"></a><a id="xml_node::empty"></a>
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: <code>if (node) { &#8230;&#8203; }</code> or <code>if (!node) { &#8230;&#8203; } else { &#8230;&#8203; }</code>. Alternatively you can check if a given <code>xml_node</code>/<code>xml_attribute</code> handle is null by calling the following methods:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-kt">bool</span> <span class="tok-n">xml_attribute</span><span class="tok-o">::</span><span class="tok-n">empty</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-kt">bool</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">empty</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>Nodes and attributes do not exist without a document tree, so you can&#8217;t create them without adding them to some document. Once underlying node/attribute objects are destroyed, the handles to those objects become invalid. While this means that destruction of the entire tree invalidates all node/attribute handles, it also means that destroying a subtree (by calling <a href="#xml_node::remove_child">xml_node::remove_child</a>) or removing an attribute invalidates the corresponding handles. There is no way to check handle validity; you have to ensure correctness through external mechanisms.</p>
</div>
</div>
<div class="sect2">
<h3 id="dom.unicode"><a class="anchor" href="#dom.unicode"></a>3.3. Unicode interface</h3>
<div class="paragraph">
<p>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 <a href="#PUGIXML_WCHAR_MODE">PUGIXML_WCHAR_MODE</a> define; you can set it via <code>pugiconfig.hpp</code> or via preprocessor options, as discussed in <a href="#install.building.config">Additional configuration options</a>. 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 is determined based on the size of <code>wchar_t</code> type.</p>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
If the size of <code>wchar_t</code> is 2, pugixml assumes UTF-16 encoding instead of UCS-2, which means that some characters are represented as two code points.
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p>All tree functions that work with strings work with either C-style null terminated strings or STL strings of the selected character type. For example, node name accessors look like this in char mode:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-k">const</span> <span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">name</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-kt">bool</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">set_name</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">value</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>and like this in wchar_t mode:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-k">const</span> <span class="tok-kt">wchar_t</span><span class="tok-o">*</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">name</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-kt">bool</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">set_name</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">wchar_t</span><span class="tok-o">*</span> <span class="tok-n">value</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p><a id="char_t"></a><a id="string_t"></a>
There is a special type, <code>pugi::char_t</code>, 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 <code>pugi::string_t</code>, which is defined as the STL string of the character type; it corresponds to <code>std::string</code> in char mode and to <code>std::wstring</code> in wchar_t mode.</p>
</div>
<div class="paragraph">
<p>In addition to the interface, the internal implementation changes to store XML data as <code>pugi::char_t</code>; this means that these two modes have different memory usage characteristics. The conversion to <code>pugi::char_t</code> upon document loading and from <code>pugi::char_t</code> upon document saving happen automatically, which also carries minor performance penalty. The general advice however is to select the character mode based on usage scenario, i.e. if UTF-8 is inconvenient to process and most of your XML data is non-ASCII, wchar_t mode is probably a better choice.</p>
</div>
<div class="paragraph">
<p><a id="as_utf8"></a><a id="as_wide"></a>
There are cases when you&#8217;ll have to convert string data between UTF-8 and wchar_t encodings; the following helper functions are provided for such purposes:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">string</span> <span class="tok-n">as_utf8</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">wchar_t</span><span class="tok-o">*</span> <span class="tok-n">str</span><span class="tok-p">);</span>
<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">wstring</span> <span class="tok-n">as_wide</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">str</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>Both functions accept a null-terminated string as an argument <code>str</code>, and return the converted string. <code>as_utf8</code> performs conversion from UTF-16/32 to UTF-8; <code>as_wide</code> performs conversion from UTF-8 to UTF-16/32. Invalid UTF sequences are silently discarded upon conversion. <code>str</code> has to be a valid string; passing null pointer results in undefined behavior. There are also two overloads with the same semantics which accept a string as an argument:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">string</span> <span class="tok-n">as_utf8</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">wstring</span><span class="tok-o">&amp;</span> <span class="tok-n">str</span><span class="tok-p">);</span>
<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">wstring</span> <span class="tok-n">as_wide</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">string</span><span class="tok-o">&amp;</span> <span class="tok-n">str</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
<div class="paragraph">
<p>Most examples in this documentation assume char interface and therefore will not compile with <a href="#PUGIXML_WCHAR_MODE">PUGIXML_WCHAR_MODE</a>. This is done to simplify the documentation; usually the only changes you&#8217;ll have to make is to pass <code>wchar_t</code> string literals, i.e. instead of</p>
</div>
<div class="paragraph">
<p><code>xml_node node = doc.child("bookstore").find_child_by_attribute("book", "id", "12345");</code></p>
</div>
<div class="paragraph">
<p>you&#8217;ll have to use</p>
</div>
<div class="paragraph">
<p><code>xml_node node = doc.child(L"bookstore").find_child_by_attribute(L"book", L"id", L"12345");</code></p>
</div>
</td>
</tr>
</table>
</div>
</div>
<div class="sect2">
<h3 id="dom.thread"><a class="anchor" href="#dom.thread"></a>3.4. Thread-safety guarantees</h3>
<div class="paragraph">
<p>Almost all functions in pugixml have the following thread-safety guarantees:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>it is safe to call free (non-member) functions from multiple threads</p>
</li>
<li>
<p>it is safe to perform concurrent read-only accesses to the same tree (all constant member functions do not modify the tree)</p>
</li>
<li>
<p>it is safe to perform concurrent read/write accesses, if there is only one read or write access to the single tree at a time</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Concurrent modification and traversing of a single tree requires synchronization, for example via reader-writer lock. Modification includes altering document structure and altering individual node/attribute data, i.e. changing names/values.</p>
</div>
<div class="paragraph">
<p>The only exception is <a href="#set_memory_management_functions">set_memory_management_functions</a>; it modifies global variables and as such is not thread-safe. Its usage policy has more restrictions, see <a href="#dom.memory.custom">Custom memory allocation/deallocation functions</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="dom.exception"><a class="anchor" href="#dom.exception"></a>3.5. Exception guarantees</h3>
<div class="paragraph">
<p>With the exception of XPath, pugixml itself does not throw any exceptions. Additionally, most pugixml functions have a no-throw exception guarantee.</p>
</div>
<div class="paragraph">
<p>This is not applicable to functions that operate on STL strings or IOstreams; such functions have either strong guarantee (functions that operate on strings) or basic guarantee (functions that operate on streams). Also functions that call user-defined callbacks (i.e. <a href="#xml_node::traverse">xml_node::traverse</a> or <a href="#xml_node::find_node">xml_node::find_node</a>) do not provide any exception guarantees beyond the ones provided by the callback.</p>
</div>
<div class="paragraph">
<p>If exception handling is not disabled with <a href="#PUGIXML_NO_EXCEPTIONS">PUGIXML_NO_EXCEPTIONS</a> define, XPath functions may throw <a href="#xpath_exception">xpath_exception</a> on parsing errors; also, XPath functions may throw <code>std::bad_alloc</code> in low memory conditions. Still, XPath functions provide strong exception guarantee.</p>
</div>
</div>
<div class="sect2">
<h3 id="dom.memory"><a class="anchor" href="#dom.memory"></a>3.6. Memory management</h3>
<div class="paragraph">
<p>pugixml requests the memory needed for document storage in big chunks, and allocates document data inside those chunks. This section discusses replacing functions used for chunk allocation and internal memory management implementation.</p>
</div>
<div class="sect3">
<h4 id="dom.memory.custom"><a class="anchor" href="#dom.memory.custom"></a>3.6.1. Custom memory allocation/deallocation functions</h4>
<div class="paragraph">
<p><a id="allocation_function"></a><a id="deallocation_function"></a>
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:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-k">typedef</span> <span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-p">(</span><span class="tok-o">*</span><span class="tok-n">allocation_function</span><span class="tok-p">)(</span><span class="tok-kt">size_t</span> <span class="tok-n">size</span><span class="tok-p">);</span>
<span class="tok-k">typedef</span> <span class="tok-nf">void</span> <span class="tok-p">(</span><span class="tok-o">*</span><span class="tok-n">deallocation_function</span><span class="tok-p">)(</span><span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-n">ptr</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p><a id="set_memory_management_functions"></a><a id="get_memory_allocation_function"></a><a id="get_memory_deallocation_function"></a>
You can use the following accessor functions to change or get current memory management functions:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-kt">void</span> <span class="tok-nf">set_memory_management_functions</span><span class="tok-p">(</span><span class="tok-n">allocation_function</span> <span class="tok-n">allocate</span><span class="tok-p">,</span> <span class="tok-n">deallocation_function</span> <span class="tok-n">deallocate</span><span class="tok-p">);</span>
<span class="tok-n">allocation_function</span> <span class="tok-nf">get_memory_allocation_function</span><span class="tok-p">();</span>
<span class="tok-n">deallocation_function</span> <span class="tok-nf">get_memory_deallocation_function</span><span class="tok-p">();</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>Allocation function is called with the size (in bytes) as an argument and should return a pointer to a memory block with alignment that is suitable for storage of primitive types (usually a maximum of <code>void*</code> and <code>double</code> types alignment is sufficient) and size that is greater than or equal to the requested one. If the allocation fails, the function has to return null pointer (throwing an exception from allocation function results in undefined behavior).</p>
</div>
<div class="paragraph">
<p>Deallocation function is called with the pointer that was returned by some call to allocation function; it is never called with a null pointer. If memory management functions are not thread-safe, library thread safety is not guaranteed.</p>
</div>
<div class="paragraph">
<p>This is a simple example of custom memory management (<a href="samples/custom_memory_management.cpp" class="bare">samples/custom_memory_management.cpp</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-nf">custom_allocate</span><span class="tok-p">(</span><span class="tok-kt">size_t</span> <span class="tok-n">size</span><span class="tok-p">)</span>
<span class="tok-p">{</span>
    <span class="tok-k">return</span> <span class="tok-k">new</span> <span class="tok-p">(</span><span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">nothrow</span><span class="tok-p">)</span> <span class="tok-kt">char</span><span class="tok-p">[</span><span class="tok-n">size</span><span class="tok-p">];</span>
<span class="tok-p">}</span>

<span class="tok-kt">void</span> <span class="tok-nf">custom_deallocate</span><span class="tok-p">(</span><span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-n">ptr</span><span class="tok-p">)</span>
<span class="tok-p">{</span>
    <span class="tok-k">delete</span><span class="tok-p">[]</span> <span class="tok-k">static_cast</span><span class="tok-o">&lt;</span><span class="tok-kt">char</span><span class="tok-o">*&gt;</span><span class="tok-p">(</span><span class="tok-n">ptr</span><span class="tok-p">);</span>
<span class="tok-p">}</span></code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">set_memory_management_functions</span><span class="tok-p">(</span><span class="tok-n">custom_allocate</span><span class="tok-p">,</span> <span class="tok-n">custom_deallocate</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>When setting new memory management functions, care must be taken to make sure that there are no live pugixml objects. Otherwise when the objects are destroyed, the new deallocation function will be called with the memory obtained by the old allocation function, resulting in undefined behavior.</p>
</div>
</div>
<div class="sect3">
<h4 id="dom.memory.tuning"><a class="anchor" href="#dom.memory.tuning"></a>3.6.2. Memory consumption tuning</h4>
<div class="paragraph">
<p>There are several important buffering optimizations in pugixml that rely on predefined constants. These constants have default values that were tuned for common usage patterns; for some applications, changing these constants might improve memory consumption or increase performance. Changing these constants is not recommended unless their default values result in visible problems.</p>
</div>
<div class="paragraph">
<p>These constants can be tuned via configuration defines, as discussed in <a href="#install.building.config">Additional configuration options</a>; it is recommended to set them in <code>pugiconfig.hpp</code>.</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>PUGIXML_MEMORY_PAGE_SIZE</code> controls the page size for document memory allocation. Memory for node/attribute objects is allocated in pages of the specified size. The default size 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.</p>
</li>
<li>
<p><code>PUGIXML_MEMORY_OUTPUT_STACK</code> controls the cumulative stack space required to output the node. Any output operation (i.e. saving a subtree to file) uses an internal buffering scheme for performance reasons. The default size is 10 Kb; if you&#8217;re using node output from threads with little stack space, decreasing this value can prevent stack overflows. A minimum size of 1 Kb is recommended.</p>
</li>
<li>
<p><code>PUGIXML_MEMORY_XPATH_PAGE_SIZE</code> controls the page size for XPath memory allocation. Memory for XPath query objects as well as internal memory for XPath evaluation is allocated in pages of the specified size. The default size is 4 Kb; if you have a lot of resident XPath query objects, you might need to decrease the size to improve memory consumption. A minimum size of 256 bytes is recommended.</p>
</li>
</ul>
</div>
</div>
<div class="sect3">
<h4 id="dom.memory.internals"><a class="anchor" href="#dom.memory.internals"></a>3.6.3. Document memory management internals</h4>
<div class="paragraph">
<p>Constructing a document object using the default constructor does not result in any allocations; document node is stored inside the <a href="#xml_document">xml_document</a> object.</p>
</div>
<div class="paragraph">
<p>When the document is loaded from file/buffer, unless an inplace loading function is used (see <a href="#loading.memory">Loading document from memory</a>), 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 <a href="#xml_document">xml_document</a> object is destroyed or if another document is loaded in the same object). Also when loading from file or stream, an additional large allocation may be performed if encoding conversion is required; a temporary buffer is allocated, and it is freed before load function returns.</p>
</div>
<div class="paragraph">
<p>All additional memory, such as memory for document structure (node/attribute objects) and memory for node/attribute names/values is allocated in pages on the order of 32 Kb; actual objects are allocated inside the pages using a memory management scheme optimized for fast allocation/deallocation of many small objects. Because of the scheme specifics, the pages are only destroyed if all objects inside them are destroyed; also, generally destroying an object does not mean that subsequent object creation will reuse the same memory. This means that it is possible to devise a usage scheme which will lead to higher memory usage than expected; one example is adding a lot of nodes, and them removing all even numbered ones; not a single page is reclaimed in the process. However this is an example specifically crafted to produce unsatisfying behavior; in all practical usage scenarios the memory consumption is less than that of a general-purpose allocator because allocation meta-data is very small in size.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="loading"><a class="anchor" href="#loading"></a>4. Loading document</h2>
<div class="sectionbody">
<div class="paragraph">
<p>pugixml provides several functions for loading XML data from various places - files, C&#43;&#43; iostreams, memory buffers. All functions use an extremely fast non-validating parser. This parser is not fully W3C conformant - it can load any valid XML document, but does not perform some well-formedness checks. While considerable effort is made to reject invalid XML documents, some validation is not performed for performance reasons. Also some XML transformations (i.e. EOL handling or attribute value normalization) can impact parsing speed and thus can be disabled. However for vast majority of XML documents there is no performance difference between different parsing options. Parsing options also control whether certain XML nodes are parsed; see <a href="#loading.options">Parsing options</a> for more information.</p>
</div>
<div class="paragraph">
<p>XML data is always converted to internal character format (see <a href="#dom.unicode">Unicode interface</a>) before parsing. pugixml supports all popular Unicode encodings (UTF-8, UTF-16 (big and little endian), UTF-32 (big and little endian); UCS-2 is naturally supported since it&#8217;s a strict subset of UTF-16) and handles all encoding conversions automatically. Unless explicit encoding is specified, loading functions perform automatic encoding detection based on first few characters of XML data, so in almost all cases you do not have to specify document encoding. Encoding conversion is described in more detail in <a href="#loading.encoding">Encodings</a>.</p>
</div>
<div class="sect2">
<h3 id="loading.file"><a class="anchor" href="#loading.file"></a>4.1. Loading document from file</h3>
<div class="paragraph">
<p><a id="xml_document::load_file"></a><a id="xml_document::load_file_wide"></a>
The most common source of XML data is files; pugixml provides dedicated functions for loading an XML document from file:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load_file</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">path</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">,</span> <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span> <span class="tok-o">=</span> <span class="tok-n">encoding_auto</span><span class="tok-p">);</span>
<span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load_file</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">wchar_t</span><span class="tok-o">*</span> <span class="tok-n">path</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">,</span> <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span> <span class="tok-o">=</span> <span class="tok-n">encoding_auto</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>These functions accept the file path as its first argument, and also two optional arguments, which specify parsing options (see <a href="#loading.options">Parsing options</a>) and input data encoding (see <a href="#loading.encoding">Encodings</a>). The path has the target operating system format, so it can be a relative or absolute one, it should have the delimiters of the target system, it should have the exact case if the target file system is case-sensitive, etc.</p>
</div>
<div class="paragraph">
<p>File path is passed to the system file opening function as is in case of the first function (which accepts <code>const char* path</code>); the second function either uses a special file opening function if it is provided by the runtime library or converts the path to UTF-8 and uses the system file opening function.</p>
</div>
<div class="paragraph">
<p><code>load_file</code> destroys the existing document tree and then tries to load the new tree from the specified file. The result of the operation is returned in an <a href="#xml_parse_result">xml_parse_result</a> object; this object contains the operation status and the related information (i.e. last successfully parsed position in the input file, if parsing fails). See <a href="#loading.errors">Handling parsing errors</a> for error handling details.</p>
</div>
<div class="paragraph">
<p>This is an example of loading XML document from file (<a href="samples/load_file.cpp" class="bare">samples/load_file.cpp</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_document</span> <span class="tok-n">doc</span><span class="tok-p">;</span>

<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_file</span><span class="tok-p">(</span><span class="tok-s">&quot;tree.xml&quot;</span><span class="tok-p">);</span>

<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;Load result: &quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">result</span><span class="tok-p">.</span><span class="tok-n">description</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;, mesh name: &quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child</span><span class="tok-p">(</span><span class="tok-s">&quot;mesh&quot;</span><span class="tok-p">).</span><span class="tok-n">attribute</span><span class="tok-p">(</span><span class="tok-s">&quot;name&quot;</span><span class="tok-p">).</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">endl</span><span class="tok-p">;</span></code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="loading.memory"><a class="anchor" href="#loading.memory"></a>4.2. Loading document from memory</h3>
<div class="paragraph">
<p><a id="xml_document::load_buffer"></a><a id="xml_document::load_buffer_inplace"></a><a id="xml_document::load_buffer_inplace_own"></a>
Sometimes XML data should be loaded from some other source than a file, i.e. HTTP URL; also you may want to load XML data from file using non-standard functions, i.e. to use your virtual file system facilities or to load XML from GZip-compressed files. All these scenarios require loading document from memory. First you should prepare a contiguous memory block with all XML data; then you have to invoke one of buffer loading functions. These functions will handle the necessary encoding conversions, if any, and then will parse the data into the corresponding XML tree. There are several buffer loading functions, which differ in the behavior and thus in performance/memory usage:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load_buffer</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-n">contents</span><span class="tok-p">,</span> <span class="tok-kt">size_t</span> <span class="tok-n">size</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">,</span> <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span> <span class="tok-o">=</span> <span class="tok-n">encoding_auto</span><span class="tok-p">);</span>
<span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load_buffer_inplace</span><span class="tok-p">(</span><span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-n">contents</span><span class="tok-p">,</span> <span class="tok-kt">size_t</span> <span class="tok-n">size</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">,</span> <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span> <span class="tok-o">=</span> <span class="tok-n">encoding_auto</span><span class="tok-p">);</span>
<span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load_buffer_inplace_own</span><span class="tok-p">(</span><span class="tok-kt">void</span><span class="tok-o">*</span> <span class="tok-n">contents</span><span class="tok-p">,</span> <span class="tok-kt">size_t</span> <span class="tok-n">size</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">,</span> <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span> <span class="tok-o">=</span> <span class="tok-n">encoding_auto</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>All functions accept the buffer which is represented by a pointer to XML data, <code>contents</code>, and data size in bytes. Also there are two optional arguments, which specify parsing options (see <a href="#loading.options">Parsing options</a>) and input data encoding (see <a href="#loading.encoding">Encodings</a>). The buffer does not have to be zero-terminated.</p>
</div>
<div class="paragraph">
<p><code>load_buffer</code> function works with immutable buffer - it does not ever modify the buffer. Because of this restriction it has to create a private buffer and copy XML data to it before parsing (applying encoding conversions if necessary). This copy operation carries a performance penalty, so inplace functions are provided - <code>load_buffer_inplace</code> and <code>load_buffer_inplace_own</code> store the document data in the buffer, modifying it in the process. In order for the document to stay valid, you have to make sure that the buffer&#8217;s lifetime exceeds that of the tree if you&#8217;re using inplace functions. In addition to that, <code>load_buffer_inplace</code> does not assume ownership of the buffer, so you&#8217;ll have to destroy it yourself; <code>load_buffer_inplace_own</code> assumes ownership of the buffer and destroys it once it is not needed. This means that if you&#8217;re using <code>load_buffer_inplace_own</code>, you have to allocate memory with pugixml allocation function (you can get it via <a href="#get_memory_allocation_function">get_memory_allocation_function</a>).</p>
</div>
<div class="paragraph">
<p>The best way from the performance/memory point of view is to load document using <code>load_buffer_inplace_own</code>; this function has maximum control of the buffer with XML data so it is able to avoid redundant copies and reduce peak memory usage while parsing. This is the recommended function if you have to load the document from memory and performance is critical.</p>
</div>
<div id="xml_document::load_string" class="paragraph">
<p>There is also a simple helper function for cases when you want to load the XML document from null-terminated character string:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-k">const</span> <span class="tok-kt">char_t</span><span class="tok-o">*</span> <span class="tok-n">contents</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>It is equivalent to calling <code>load_buffer</code> with <code>size</code> being either <code>strlen(contents)</code> or <code>wcslen(contents) * sizeof(wchar_t)</code>, depending on the character type. This function assumes native encoding for input data, so it does not do any encoding conversion. In general, this function is fine for loading small documents from string literals, but has more overhead and less functionality than the buffer loading functions.</p>
</div>
<div class="paragraph">
<p>This is an example of loading XML document from memory using different functions (<a href="samples/load_memory.cpp" class="bare">samples/load_memory.cpp</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-k">const</span> <span class="tok-kt">char</span> <span class="tok-n">source</span><span class="tok-p">[]</span> <span class="tok-o">=</span> <span class="tok-s">&quot;&lt;mesh name=&#39;sphere&#39;&gt;&lt;bounds&gt;0 0 1 1&lt;/bounds&gt;&lt;/mesh&gt;&quot;</span><span class="tok-p">;</span>
<span class="tok-kt">size_t</span> <span class="tok-n">size</span> <span class="tok-o">=</span> <span class="tok-k">sizeof</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-c1">// You can use load_buffer to load document from immutable memory block:</span>
<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_buffer</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">,</span> <span class="tok-n">size</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-c1">// You can use load_buffer_inplace to load document from mutable memory block; the block&#39;s lifetime must exceed that of document</span>
<span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">buffer</span> <span class="tok-o">=</span> <span class="tok-k">new</span> <span class="tok-kt">char</span><span class="tok-p">[</span><span class="tok-n">size</span><span class="tok-p">];</span>
<span class="tok-n">memcpy</span><span class="tok-p">(</span><span class="tok-n">buffer</span><span class="tok-p">,</span> <span class="tok-n">source</span><span class="tok-p">,</span> <span class="tok-n">size</span><span class="tok-p">);</span>

<span class="tok-c1">// The block can be allocated by any method; the block is modified during parsing</span>
<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_buffer_inplace</span><span class="tok-p">(</span><span class="tok-n">buffer</span><span class="tok-p">,</span> <span class="tok-n">size</span><span class="tok-p">);</span>

<span class="tok-c1">// You have to destroy the block yourself after the document is no longer used</span>
<span class="tok-k">delete</span><span class="tok-p">[]</span> <span class="tok-n">buffer</span><span class="tok-p">;</span></code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-c1">// You can use load_buffer_inplace_own to load document from mutable memory block and to pass the ownership of this block</span>
<span class="tok-c1">// The block has to be allocated via pugixml allocation function - using i.e. operator new here is incorrect</span>
<span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">buffer</span> <span class="tok-o">=</span> <span class="tok-k">static_cast</span><span class="tok-o">&lt;</span><span class="tok-kt">char</span><span class="tok-o">*&gt;</span><span class="tok-p">(</span><span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">get_memory_allocation_function</span><span class="tok-p">()(</span><span class="tok-n">size</span><span class="tok-p">));</span>
<span class="tok-n">memcpy</span><span class="tok-p">(</span><span class="tok-n">buffer</span><span class="tok-p">,</span> <span class="tok-n">source</span><span class="tok-p">,</span> <span class="tok-n">size</span><span class="tok-p">);</span>

<span class="tok-c1">// The block will be deleted by the document</span>
<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_buffer_inplace_own</span><span class="tok-p">(</span><span class="tok-n">buffer</span><span class="tok-p">,</span> <span class="tok-n">size</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-c1">// You can use load to load document from null-terminated strings, for example literals:</span>
<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-s">&quot;&lt;mesh name=&#39;sphere&#39;&gt;&lt;bounds&gt;0 0 1 1&lt;/bounds&gt;&lt;/mesh&gt;&quot;</span><span class="tok-p">);</span></code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="loading.stream"><a class="anchor" href="#loading.stream"></a>4.3. Loading document from C&#43;&#43; IOstreams</h3>
<div id="xml_document::load_stream" class="paragraph">
<p>To enhance interoperability, pugixml provides functions for loading document from any object which implements C&#43;&#43; <code>std::istream</code> interface. This allows you to load documents from any standard C&#43;&#43; stream (i.e. file stream) or any third-party compliant implementation (i.e. Boost Iostreams). There are two functions, one works with narrow character streams, another handles wide character ones:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load</span><span class="tok-p">(</span><span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">istream</span><span class="tok-o">&amp;</span> <span class="tok-n">stream</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">,</span> <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span> <span class="tok-o">=</span> <span class="tok-n">encoding_auto</span><span class="tok-p">);</span>
<span class="tok-n">xml_parse_result</span> <span class="tok-n">xml_document</span><span class="tok-o">::</span><span class="tok-n">load</span><span class="tok-p">(</span><span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">wistream</span><span class="tok-o">&amp;</span> <span class="tok-n">stream</span><span class="tok-p">,</span> <span class="tok-kt">unsigned</span> <span class="tok-kt">int</span> <span class="tok-n">options</span> <span class="tok-o">=</span> <span class="tok-n">parse_default</span><span class="tok-p">);</span></code></pre>
</div>
</div>
<div class="paragraph">
<p><code>load</code> with <code>std::istream</code> argument loads the document from stream from the current read position to the end, treating the stream contents as a byte stream of the specified encoding (with encoding autodetection as necessary). Thus calling <code>xml_document::load</code> on an opened <code>std::ifstream</code> object is equivalent to calling <code>xml_document::load_file</code>.</p>
</div>
<div class="paragraph">
<p><code>load</code> with <code>std::wstream</code> argument treats the stream contents as a wide character stream (encoding is always <a href="#encoding_wchar">encoding_wchar</a>). Because of this, using <code>load</code> with wide character streams requires careful (usually platform-specific) stream setup (i.e. using the <code>imbue</code> function). Generally use of wide streams is discouraged, however it provides you the ability to load documents from non-Unicode encodings, i.e. you can load Shift-JIS encoded data if you set the correct locale.</p>
</div>
<div class="paragraph">
<p>This is a simple example of loading XML document from file using streams (<a href="samples/load_stream.cpp" class="bare">samples/load_stream.cpp</a>); read the sample code for more complex examples involving wide streams and locales:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">ifstream</span> <span class="tok-n">stream</span><span class="tok-p">(</span><span class="tok-s">&quot;weekly-utf-8.xml&quot;</span><span class="tok-p">);</span>
<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load</span><span class="tok-p">(</span><span class="tok-n">stream</span><span class="tok-p">);</span></code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="loading.errors"><a class="anchor" href="#loading.errors"></a>4.4. Handling parsing errors</h3>
<div id="xml_parse_result" class="paragraph">
<p>All document loading functions return the parsing result via <code>xml_parse_result</code> object. It contains parsing status, the offset of last successfully parsed character from the beginning of the source stream, and the encoding of the source stream:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-k">struct</span> <span class="tok-n">xml_parse_result</span>
<span class="tok-p">{</span>
    <span class="tok-n">xml_parse_status</span> <span class="tok-n">status</span><span class="tok-p">;</span>
    <span class="tok-kt">ptrdiff_t</span> <span class="tok-n">offset</span><span class="tok-p">;</span>
    <span class="tok-n">xml_encoding</span> <span class="tok-n">encoding</span><span class="tok-p">;</span>

    <span class="tok-k">operator</span> <span class="tok-kt">bool</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
    <span class="tok-k">const</span> <span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">description</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-p">};</span></code></pre>
</div>
</div>
<div class="paragraph">
<p><a id="xml_parse_status"></a><a id="xml_parse_result::status"></a>
Parsing status is represented as the <code>xml_parse_status</code> enumeration and can be one of the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a id="status_ok"></a><code>status_ok</code> means that no error was encountered during parsing; the source stream represents the valid XML document which was fully parsed and converted to a tree.</p>
</li>
<li>
<p><a id="status_file_not_found"></a><code>status_file_not_found</code> is only returned by <code>load_file</code> function and means that file could not be opened.</p>
</li>
<li>
<p><a id="status_io_error"></a><code>status_io_error</code> is returned by <code>load_file</code> function and by <code>load</code> functions with <code>std::istream</code>/<code>std::wstream</code> arguments; it means that some I/O error has occurred during reading the file/stream.</p>
</li>
<li>
<p><a id="status_out_of_memory"></a><code>status_out_of_memory</code> means that there was not enough memory during some allocation; any allocation failure during parsing results in this error.</p>
</li>
<li>
<p><a id="status_internal_error"></a><code>status_internal_error</code> means that something went horribly wrong; currently this error does not occur</p>
</li>
<li>
<p><a id="status_unrecognized_tag"></a><code>status_unrecognized_tag</code> means that parsing stopped due to a tag with either an empty name or a name which starts with incorrect character, such as <code>#</code>.</p>
</li>
<li>
<p><a id="status_bad_pi"></a><code>status_bad_pi</code> means that parsing stopped due to incorrect document declaration/processing instruction</p>
</li>
<li>
<p><a id="status_bad_comment"></a><code>status_bad_comment</code>, <a id="status_bad_cdata"></a><code>status_bad_cdata</code>, <a id="status_bad_doctype"></a><code>status_bad_doctype</code> and <a id="status_bad_pcdata"></a><code>status_bad_pcdata</code> mean that parsing stopped due to the invalid construct of the respective type</p>
</li>
<li>
<p><a id="status_bad_start_element"></a><code>status_bad_start_element</code> means that parsing stopped because starting tag either had no closing <code>&gt;</code> symbol or contained some incorrect symbol</p>
</li>
<li>
<p><a id="status_bad_attribute"></a><code>status_bad_attribute</code> means that parsing stopped because there was an incorrect attribute, such as an attribute without value or with value that is not quoted (note that <code>&lt;node attr=1&gt;</code> is incorrect in XML)</p>
</li>
<li>
<p><a id="status_bad_end_element"></a><code>status_bad_end_element</code> means that parsing stopped because ending tag had incorrect syntax (i.e. extra non-whitespace symbols between tag name and <code>&gt;</code>)</p>
</li>
<li>
<p><a id="status_end_element_mismatch"></a><code>status_end_element_mismatch</code> means that parsing stopped because the closing tag did not match the opening one (i.e. <code>&lt;node&gt;&lt;/nedo&gt;</code>) or because some tag was not closed at all</p>
</li>
<li>
<p><a id="status_no_document_element"></a><code>status_no_document_element</code> means that no element nodes were discovered during parsing; this usually indicates an empty or invalid document</p>
</li>
</ul>
</div>
<div id="xml_parse_result::description" class="paragraph">
<p><code>description()</code> member function can be used to convert parsing status to a string; the returned message is always in English, so you&#8217;ll have to write your own function if you need a localized string. However please note that the exact messages returned by <code>description()</code> function may change from version to version, so any complex status handling should be based on <code>status</code> value. Note that <code>description()</code> returns a <code>char</code> string even in <code>PUGIXML_WCHAR_MODE</code>; you&#8217;ll have to call <a href="#as_wide">as_wide</a> to get the <code>wchar_t</code> string.</p>
</div>
<div class="paragraph">
<p>If parsing failed because the source data was not a valid XML, the resulting tree is not destroyed - despite the fact that load function returns error, you can use the part of the tree that was successfully parsed. Obviously, the last element may have an unexpected name/value; for example, if the attribute value does not end with the necessary quotation mark, like in <code>&lt;node attr="value&gt;some data&lt;/node&gt;</code> example, the value of attribute <code>attr</code> will contain the string <code>value&gt;some data&lt;/node&gt;</code>.</p>
</div>
<div id="xml_parse_result::offset" class="paragraph">
<p>In addition to the status code, parsing result has an <code>offset</code> member, which contains the offset of last successfully parsed character if parsing failed because of an error in source data; otherwise <code>offset</code> is 0. For parsing efficiency reasons, pugixml does not track the current line during parsing; this offset is in units of <a href="#char_t">pugi::char_t</a> (bytes for character mode, wide characters for wide character mode). Many text editors support 'Go To Position' feature - you can use it to locate the exact error position. Alternatively, if you&#8217;re loading the document from memory, you can display the error chunk along with the error description (see the example code below).</p>
</div>
<div class="admonitionblock caution">
<table>
<tr>
<td class="icon">
<div class="title">Caution</div>
</td>
<td class="content">
Offset is calculated in the XML buffer in native encoding; if encoding conversion is performed during parsing, offset can not be used to reliably track the error position.
</td>
</tr>
</table>
</div>
<div id="xml_parse_result::encoding" class="paragraph">
<p>Parsing result also has an <code>encoding</code> member, which can be used to check that the source data encoding was correctly guessed. It is equal to the exact encoding used during parsing (i.e. with the exact endianness); see <a href="#loading.encoding">Encodings</a> for more information.</p>
</div>
<div id="xml_parse_result::bool" class="paragraph">
<p>Parsing result object can be implicitly converted to <code>bool</code>; if you do not want to handle parsing errors thoroughly, you can just check the return value of load functions as if it was a <code>bool</code>: <code>if (doc.load_file("file.xml")) { &#8230;&#8203; } else { &#8230;&#8203; }</code>.</p>
</div>
<div class="paragraph">
<p>This is an example of handling loading errors (<a href="samples/load_error_handling.cpp" class="bare">samples/load_error_handling.cpp</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_document</span> <span class="tok-n">doc</span><span class="tok-p">;</span>
<span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">xml_parse_result</span> <span class="tok-n">result</span> <span class="tok-o">=</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">);</span>

<span class="tok-k">if</span> <span class="tok-p">(</span><span class="tok-n">result</span><span class="tok-p">)</span>
<span class="tok-p">{</span>
    <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;XML [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">source</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;] parsed without errors, attr value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child</span><span class="tok-p">(</span><span class="tok-s">&quot;node&quot;</span><span class="tok-p">).</span><span class="tok-n">attribute</span><span class="tok-p">(</span><span class="tok-s">&quot;attr&quot;</span><span class="tok-p">).</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>
<span class="tok-p">}</span>
<span class="tok-k">else</span>
<span class="tok-p">{</span>
    <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;XML [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">source</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;] parsed with errors, attr value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child</span><span class="tok-p">(</span><span class="tok-s">&quot;node&quot;</span><span class="tok-p">).</span><span class="tok-n">attribute</span><span class="tok-p">(</span><span class="tok-s">&quot;attr&quot;</span><span class="tok-p">).</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>
    <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;Error description: &quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">result</span><span class="tok-p">.</span><span class="tok-n">description</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;</span><span class="tok-se">\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>
    <span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;Error offset: &quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">result</span><span class="tok-p">.</span><span class="tok-n">offset</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot; (error at [...&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-p">(</span><span class="tok-n">source</span> <span class="tok-o">+</span> <span class="tok-n">result</span><span class="tok-p">.</span><span class="tok-n">offset</span><span class="tok-p">)</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>
<span class="tok-p">}</span></code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="loading.options"><a class="anchor" href="#loading.options"></a>4.5. Parsing options</h3>
<div class="paragraph">
<p>All document loading functions accept the optional parameter <code>options</code>. This is a bitmask that customizes the parsing process: you can select the node types that are parsed and various transformations that are performed with the XML text. Disabling certain transformations can improve parsing performance for some documents; however, the code for all transformations is very well optimized, and thus the majority of documents won&#8217;t get any performance benefit. As a rule of thumb, only modify parsing flags if you want to get some nodes in the document that are excluded by default (i.e. declaration or comment nodes).</p>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
You should use the usual bitwise arithmetics to manipulate the bitmask: to enable a flag, use <code>mask | flag</code>; to disable a flag, use <code>mask &amp; ~flag</code>.
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p>These flags control the resulting tree contents:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a id="parse_declaration"></a><code>parse_declaration</code> determines if XML document declaration (node with type <a href="#node_declaration">node_declaration</a>) is to be put in DOM tree. If this flag is off, it is not put in the tree, but is still parsed and checked for correctness. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_doctype"></a><code>parse_doctype</code> determines if XML document type declaration (node with type <a href="#node_doctype">node_doctype</a>) is to be put in DOM tree. If this flag is off, it is not put in the tree, but is still parsed and checked for correctness. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_pi"></a><code>parse_pi</code> determines if processing instructions (nodes with type <a href="#node_pi">node_pi</a>) are to be put in DOM tree. If this flag is off, they are not put in the tree, but are still parsed and checked for correctness. Note that <code>&lt;?xml &#8230;&#8203;?&gt;</code> (document declaration) is not considered to be a PI. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_comments"></a><code>parse_comments</code> determines if comments (nodes with type <a href="#node_comment">node_comment</a>) are to be put in DOM tree. If this flag is off, they are not put in the tree, but are still parsed and checked for correctness. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_cdata"></a><code>parse_cdata</code> determines if CDATA sections (nodes with type <a href="#node_cdata">node_cdata</a>) are to be put in DOM tree. If this flag is off, they are not put in the tree, but are still parsed and checked for correctness. This flag is <strong>on</strong> by default.</p>
</li>
<li>
<p><a id="parse_trim_pcdata"></a><code>parse_trim_pcdata</code> determines if leading and trailing whitespace characters are to be removed from PCDATA nodes. While for some applications leading/trailing whitespace is significant, often the application only cares about the non-whitespace contents so it&#8217;s easier to trim whitespace from text during parsing. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_ws_pcdata"></a><code>parse_ws_pcdata</code> determines if PCDATA nodes (nodes with type <a href="#node_pcdata">node_pcdata</a>) that consist only of whitespace characters are to be put in DOM tree. Often whitespace-only data is not significant for the application, and the cost of allocating and storing such nodes (both memory and speed-wise) can be significant. For example, after parsing XML string <code>&lt;node&gt; &lt;a/&gt; &lt;/node&gt;</code>, <code>&lt;node&gt;</code> element will have three children when <code>parse_ws_pcdata</code> is set (child with type <a href="#node_pcdata">node_pcdata</a> and value <code>" "</code>, child with type <a href="#node_element">node_element</a> and name <code>"a"</code>, and another child with type <a href="#node_pcdata">node_pcdata</a> and value <code>" "</code>), and only one child when <code>parse_ws_pcdata</code> is not set. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_ws_pcdata_single"></a><code>parse_ws_pcdata_single</code> determines if whitespace-only PCDATA nodes that have no sibling nodes are to be put in DOM tree. In some cases application needs to parse the whitespace-only contents of nodes, i.e. <code>&lt;node&gt;  &lt;/node&gt;</code>, but is not interested in whitespace markup elsewhere. It is possible to use <a href="#parse_ws_pcdata">parse_ws_pcdata</a> flag in this case, but it results in excessive allocations and complicates document processing; this flag can be used to avoid that. As an example, after parsing XML string <code>&lt;node&gt; &lt;a&gt;  &lt;/a&gt; &lt;/node&gt;</code> with <code>parse_ws_pcdata_single</code> flag set, <code>&lt;node&gt;</code> element will have one child <code>&lt;a&gt;</code>, and <code>&lt;a&gt;</code> element will have one child with type <a href="#node_pcdata">node_pcdata</a> and value <code>"  "</code>. This flag has no effect if <a href="#parse_ws_pcdata">parse_ws_pcdata</a> is enabled. This flag is <strong>off</strong> by default.</p>
</li>
<li>
<p><a id="parse_fragment"></a><code>parse_fragment</code> determines if document should be treated as a fragment of a valid XML. Parsing document as a fragment leads to top-level PCDATA content (i.e. text that is not located inside a node) to be added to a tree, and additionally treats documents without element nodes as valid. This flag is <strong>off</strong> by default.</p>
</li>
</ul>
</div>
<div class="admonitionblock caution">
<table>
<tr>
<td class="icon">
<div class="title">Caution</div>
</td>
<td class="content">
Using in-place parsing (<a href="#xml_document::load_buffer_inplace">load_buffer_inplace</a>) with <code>parse_fragment</code> flag may result in the loss of the last character of the buffer if it is a part of PCDATA. Since PCDATA values are null-terminated strings, the only way to resolve this is to provide a null-terminated buffer as an input to <code>load_buffer_inplace</code> - i.e. <code>doc.load_buffer_inplace("test\0", 5, pugi::parse_default | pugi::parse_fragment)</code>.
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p>These flags control the transformation of tree element contents:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a id="parse_escapes"></a><code>parse_escapes</code> determines if character and entity references are to be expanded during the parsing process. Character references have the form <code>&amp;#&#8230;&#8203;;</code> or <code>&amp;#x&#8230;&#8203;;</code> (<code>&#8230;&#8203;</code> is Unicode numeric representation of character in either decimal (<code>&amp;#&#8230;&#8203;;</code>) or hexadecimal (<code>&amp;#x&#8230;&#8203;;</code>) form), entity references are <code>&amp;lt;</code>, <code>&amp;gt;</code>, <code>&amp;amp;</code>, <code>&amp;apos;</code> and <code>&amp;quot;</code> (note that as pugixml does not handle DTD, the only allowed entities are predefined ones). If character/entity reference can not be expanded, it is left as is, so you can do additional processing later. Reference expansion is performed on attribute values and PCDATA content. This flag is <strong>on</strong> by default.</p>
</li>
<li>
<p><a id="parse_eol"></a><code>parse_eol</code> determines if EOL handling (that is, replacing sequences <code>\r\n</code> by a single <code>\n</code> character, and replacing all standalone <code>\r</code> characters by <code>\n</code>) is to be performed on input data (that is, comment contents, PCDATA/CDATA contents and attribute values). This flag is <strong>on</strong> by default.</p>
</li>
<li>
<p><a id="parse_wconv_attribute"></a><code>parse_wconv_attribute</code> determines if attribute value normalization should be performed for all attributes. This means, that whitespace characters (new line, tab and space) are replaced with space (<code>' '</code>). New line characters are always treated as if <a href="#parse_eol">parse_eol</a> is set, i.e. <code>\r\n</code> is converted to a single space.  This flag is <strong>on</strong> by default.</p>
</li>
<li>
<p><a id="parse_wnorm_attribute"></a><code>parse_wnorm_attribute</code> determines if extended attribute value normalization should be performed for all attributes. This means, that after attribute values are normalized as if <a href="#parse_wconv_attribute">parse_wconv_attribute</a> was set, leading and trailing space characters are removed, and all sequences of space characters are replaced by a single space character. <a href="#parse_wconv_attribute">parse_wconv_attribute</a> has no effect if this flag is on. This flag is <strong>off</strong> by default.</p>
</li>
</ul>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
<code>parse_wconv_attribute</code> option performs transformations that are required by W3C specification for attributes that are declared as CDATA; <a href="#parse_wnorm_attribute">parse_wnorm_attribute</a> performs transformations required for NMTOKENS attributes. In the absence of document type declaration all attributes should behave as if they are declared as CDATA, thus <a href="#parse_wconv_attribute">parse_wconv_attribute</a> is the default option.
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p>Additionally there are three predefined option masks:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a id="parse_minimal"></a><code>parse_minimal</code> has all options turned off. This option mask means that pugixml does not add declaration nodes, document type declaration nodes, PI nodes, CDATA sections and comments to the resulting tree and does not perform any conversion for input data, so theoretically it is the fastest mode. However, as mentioned above, in practice <a href="#parse_default">parse_default</a> is usually equally fast.</p>
</li>
<li>
<p><a id="parse_default"></a><code>parse_default</code> is the default set of flags, i.e. it has all options set to their default values. It includes parsing CDATA sections (comments/PIs are not parsed), performing character and entity reference expansion, replacing whitespace characters with spaces in attribute values and performing EOL handling. Note, that PCDATA sections consisting only of whitespace characters are not parsed (by default) for performance reasons.</p>
</li>
<li>
<p><a id="parse_full"></a><code>parse_full</code> is the set of flags which adds nodes of all types to the resulting tree and performs default conversions for input data. It includes parsing CDATA sections, comments, PI nodes, document declaration node and document type declaration node, performing character and entity reference expansion, replacing whitespace characters with spaces in attribute values and performing EOL handling. Note, that PCDATA sections consisting only of whitespace characters are not parsed in this mode.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>This is an example of using different parsing options (<a href="samples/load_options.cpp" class="bare">samples/load_options.cpp</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-k">const</span> <span class="tok-kt">char</span><span class="tok-o">*</span> <span class="tok-n">source</span> <span class="tok-o">=</span> <span class="tok-s">&quot;&lt;!--comment--&gt;&lt;node&gt;&amp;lt;&lt;/node&gt;&quot;</span><span class="tok-p">;</span>

<span class="tok-c1">// Parsing with default options; note that comment node is not added to the tree, and entity reference &amp;lt; is expanded</span>
<span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">);</span>
<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;First node value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">first_child</span><span class="tok-p">().</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;], node child value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child_value</span><span class="tok-p">(</span><span class="tok-s">&quot;node&quot;</span><span class="tok-p">)</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>

<span class="tok-c1">// Parsing with additional parse_comments option; comment node is now added to the tree</span>
<span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">,</span> <span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">parse_default</span> <span class="tok-o">|</span> <span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">parse_comments</span><span class="tok-p">);</span>
<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;First node value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">first_child</span><span class="tok-p">().</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;], node child value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child_value</span><span class="tok-p">(</span><span class="tok-s">&quot;node&quot;</span><span class="tok-p">)</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>

<span class="tok-c1">// Parsing with additional parse_comments option and without the (default) parse_escapes option; &amp;lt; is not expanded</span>
<span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">,</span> <span class="tok-p">(</span><span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">parse_default</span> <span class="tok-o">|</span> <span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">parse_comments</span><span class="tok-p">)</span> <span class="tok-o">&amp;</span> <span class="tok-o">~</span><span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">parse_escapes</span><span class="tok-p">);</span>
<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;First node value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">first_child</span><span class="tok-p">().</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;], node child value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child_value</span><span class="tok-p">(</span><span class="tok-s">&quot;node&quot;</span><span class="tok-p">)</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span>

<span class="tok-c1">// Parsing with minimal option mask; comment node is not added to the tree, and &amp;lt; is not expanded</span>
<span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">load_string</span><span class="tok-p">(</span><span class="tok-n">source</span><span class="tok-p">,</span> <span class="tok-n">pugi</span><span class="tok-o">::</span><span class="tok-n">parse_minimal</span><span class="tok-p">);</span>
<span class="tok-n">std</span><span class="tok-o">::</span><span class="tok-n">cout</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;First node value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">first_child</span><span class="tok-p">().</span><span class="tok-n">value</span><span class="tok-p">()</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;], node child value: [&quot;</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-n">doc</span><span class="tok-p">.</span><span class="tok-n">child_value</span><span class="tok-p">(</span><span class="tok-s">&quot;node&quot;</span><span class="tok-p">)</span> <span class="tok-o">&lt;&lt;</span> <span class="tok-s">&quot;]</span><span class="tok-se">\n</span><span class="tok-s">&quot;</span><span class="tok-p">;</span></code></pre>
</div>
</div>
</div>
<div class="sect2">
<h3 id="loading.encoding"><a class="anchor" href="#loading.encoding"></a>4.6. Encodings</h3>
<div id="xml_encoding" class="paragraph">
<p>pugixml supports all popular Unicode encodings (UTF-8, UTF-16 (big and little endian), UTF-32 (big and little endian); UCS-2 is naturally supported since it&#8217;s a strict subset of UTF-16) and handles all encoding conversions. Most loading functions accept the optional parameter <code>encoding</code>. This is a value of enumeration type <code>xml_encoding</code>, that can have the following values:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a id="encoding_auto"></a><code>encoding_auto</code> means that pugixml will try to guess the encoding based on source XML data. The algorithm is a modified version of the one presented in <a href="http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info">Appendix F.1 of XML recommendation</a>; it tries to match the first few bytes of input data with the following patterns in strict order:</p>
<div class="ulist">
<ul>
<li>
<p>If first four bytes match UTF-32 BOM (Byte Order Mark), encoding is assumed to be UTF-32 with the endianness equal to that of BOM;</p>
</li>
<li>
<p>If first two bytes match UTF-16 BOM, encoding is assumed to be UTF-16 with the endianness equal to that of BOM;</p>
</li>
<li>
<p>If first three bytes match UTF-8 BOM, encoding is assumed to be UTF-8;</p>
</li>
<li>
<p>If first four bytes match UTF-32 representation of <code>&lt;</code>, encoding is assumed to be UTF-32 with the corresponding endianness;</p>
</li>
<li>
<p>If first four bytes match UTF-16 representation of <code>&lt;?</code>, encoding is assumed to be UTF-16 with the corresponding endianness;</p>
</li>
<li>
<p>If first two bytes match UTF-16 representation of <code>&lt;</code>, encoding is assumed to be UTF-16 with the corresponding endianness (this guess may yield incorrect result, but it&#8217;s better than UTF-8);</p>
</li>
<li>
<p>Otherwise encoding is assumed to be UTF-8.</p>
</li>
</ul>
</div>
</li>
<li>
<p><a id="encoding_utf8"></a><code>encoding_utf8</code> corresponds to UTF-8 encoding as defined in the Unicode standard; UTF-8 sequences with length equal to 5 or 6 are not standard and are rejected.</p>
</li>
<li>
<p><a id="encoding_utf16_le"></a><code>encoding_utf16_le</code> corresponds to little-endian UTF-16 encoding as defined in the Unicode standard; surrogate pairs are supported.</p>
</li>
<li>
<p><a id="encoding_utf16_be"></a><code>encoding_utf16_be</code> corresponds to big-endian UTF-16 encoding as defined in the Unicode standard; surrogate pairs are supported.</p>
</li>
<li>
<p><a id="encoding_utf16"></a><code>encoding_utf16</code> corresponds to UTF-16 encoding as defined in the Unicode standard; the endianness is assumed to be that of the target platform.</p>
</li>
<li>
<p><a id="encoding_utf32_le"></a><code>encoding_utf32_le</code> corresponds to little-endian UTF-32 encoding as defined in the Unicode standard.</p>
</li>
<li>
<p><a id="encoding_utf32_be"></a><code>encoding_utf32_be</code> corresponds to big-endian UTF-32 encoding as defined in the Unicode standard.</p>
</li>
<li>
<p><a id="encoding_utf32"></a><code>encoding_utf32</code> corresponds to UTF-32 encoding as defined in the Unicode standard; the endianness is assumed to be that of the target platform.</p>
</li>
<li>
<p><a id="encoding_wchar"></a><code>encoding_wchar</code> corresponds to the encoding of <code>wchar_t</code> type; it has the same meaning as either <code>encoding_utf16</code> or <code>encoding_utf32</code>, depending on <code>wchar_t</code> size.</p>
</li>
<li>
<p><a id="encoding_latin1"></a><code>encoding_latin1</code> corresponds to ISO-8859-1 encoding (also known as Latin-1).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The algorithm used for <code>encoding_auto</code> correctly detects any supported Unicode encoding for all well-formed XML documents (since they start with document declaration) and for all other XML documents that start with <code>&lt;</code>; if your XML document does not start with <code>&lt;</code> and has encoding that is different from UTF-8, use the specific encoding.</p>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
The current behavior for Unicode conversion is to skip all invalid UTF sequences during conversion. This behavior should not be relied upon; moreover, in case no encoding conversion is performed, the invalid sequences are not removed, so you&#8217;ll get them as is in node/attribute contents.
</td>
</tr>
</table>
</div>
</div>
<div class="sect2">
<h3 id="loading.w3c"><a class="anchor" href="#loading.w3c"></a>4.7. Conformance to W3C specification</h3>
<div class="paragraph">
<p>pugixml is not fully W3C conformant - it can load any valid XML document, but does not perform some well-formedness checks. While considerable effort is made to reject invalid XML documents, some validation is not performed because of performance reasons.</p>
</div>
<div class="paragraph">
<p>There is only one non-conformant behavior when dealing with valid XML documents: pugixml does not use information supplied in document type declaration for parsing. This means that entities declared in DOCTYPE are not expanded, and all attribute/PCDATA values are always processed in a uniform way that depends only on parsing options.</p>
</div>
<div class="paragraph">
<p>As for rejecting invalid XML documents, there are a number of incompatibilities with W3C specification, including:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Multiple attributes of the same node can have equal names.</p>
</li>
<li>
<p>All non-ASCII characters are treated in the same way as symbols of English alphabet, so some invalid tag names are not rejected.</p>
</li>
<li>
<p>Attribute values which contain <code>&lt;</code> are not rejected.</p>
</li>
<li>
<p>Invalid entity/character references are not rejected and are instead left as is.</p>
</li>
<li>
<p>Comment values can contain <code>--</code>.</p>
</li>
<li>
<p>XML data is not required to begin with document declaration; additionally, document declaration can appear after comments and other nodes.</p>
</li>
<li>
<p>Invalid document type declarations are silently ignored in some cases.</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="access"><a class="anchor" href="#access"></a>5. Accessing document data</h2>
<div class="sectionbody">
<div class="paragraph">
<p>pugixml features an extensive interface for getting various types of data from the document and for traversing the document. This section provides documentation for all such functions that do not modify the tree except for XPath-related functions; see <a href="#xpath">XPath</a> for XPath reference. As discussed in <a href="#dom.cpp">C&#43;&#43; interface</a>, there are two types of handles to tree data - <a href="#xml_node">xml_node</a> and <a href="#xml_attribute">xml_attribute</a>. The handles have special null (empty) values which propagate through various functions and thus are useful for writing more concise code; see <a href="#node_null">this description</a> for details. The documentation in this section will explicitly state the results of all function in case of null inputs.</p>
</div>
<div class="sect2">
<h3 id="access.basic"><a class="anchor" href="#access.basic"></a>5.1. Basic traversal functions</h3>
<div class="paragraph">
<p><a id="xml_node::parent"></a><a id="xml_node::first_child"></a><a id="xml_node::last_child"></a><a id="xml_node::next_sibling"></a><a id="xml_node::previous_sibling"></a><a id="xml_node::first_attribute"></a><a id="xml_node::last_attribute"></a><a id="xml_attribute::next_attribute"></a><a id="xml_attribute::previous_attribute"></a>
The internal representation of the document is a tree, where each node has a list of child nodes (the order of children corresponds to their order in the XML representation), and additionally element nodes have a list of attributes, which is also ordered. Several functions are provided in order to let you get from one node in the tree to the other. These functions roughly correspond to the internal representation, and thus are usually building blocks for other methods of traversing (i.e. XPath traversals are based on these functions).</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="c++"><span class="tok-n">xml_node</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">parent</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_node</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">first_child</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_node</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">last_child</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_node</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">next_sibling</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_node</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">previous_sibling</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>

<span class="tok-n">xml_attribute</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">first_attribute</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_attribute</span> <span class="tok-n">xml_node</span><span class="tok-o">::</span><span class="tok-n">last_attribute</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_attribute</span> <span class="tok-n">xml_attribute</span><span class="tok-o">::</span><span class="tok-n">next_attribute</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span>
<span class="tok-n">xml_attribute</span> <span class="tok-n">xml_attribute</span><span class="tok-o">::</span><span class="tok-n">previous_attribute</span><span class="tok-p">()</span> <span class="tok-k">const</span><span class="tok-p">;</span></code></pre>
</div>
</div>
<div class="paragraph">
<p><code>parent</code> function returns the node&#8217;s parent; all non-null nodes except the document have non-null parent. <code>first_child</code> and <code>last_child</code> return the first and last child of the node, respectively; note that only document nodes and element nodes can have non-empty child node list. If node has no children, both functions return null nodes. <code>next_sibling</code> and <code>previous_sibling</code> return the node that&#8217;s immediately to the right/left of this node in the children list, respectively - for example, in <code>&lt;a/&gt;&lt;b/&gt;&lt;c/&gt;</code>, calling <code>next_sibling</code> for a handle that points to <code>&lt;b/&gt;</code> results in a handle pointing to <code>&lt;c/&gt;</code>, and calling <code>previous_sibling</code> results in handle pointing to <code>&lt;a/&gt;</code>. If node does not have next/previous sibling (this happens if it is the last/first node in the list, respectively), the functions return null nodes. <code>first_attribute</code>, <code>last_attribute</code>, <code>next_attribute</code> and <code>previous_attribute</code> functions behave similarly to the corresponding child node functions and allow to iterate through attribute list in the same way.</p>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">