anchor.diff:  [[saving.stream]]
   === Saving document to C{plus}{plus} IOstreams
   
  -[#xml_document::save_stream]
  +[[xml_document::save_stream]]
   To enhance interoperability pugixml provides functions for saving document to any object which implements C{plus}{plus} `std::ostream` interface. This allows you to save documents to any standard C{plus}{plus} stream (i.e. file stream) or any third-party compliant implementation (i.e. Boost Iostreams). Most notably, this allows for easy debug output, since you can use `std::cout` stream as saving target. There are two functions, one works with narrow character streams, another handles wide character ones:
   
   [source]
  
positive.code: 
  The attribute is copied along with the name and value; the node is copied along with its type, name and value; additionally attribute list and all children are recursively cloned, resulting in the deep subtree clone. The prototype object can be a part of the same document, or a part of any other document.
  
  The failure conditions resemble those of `append_child`, `insert_child_before` and related functions, [link xml_node::append_child consult their documentation for more information]. There are additional caveats specific to cloning functions:
  
  * Cloning null handles results in operation failure;
  * Node cloning starts with insertion of the node of the same type as that of the prototype; for this reason, cloning functions can not be directly used to clone entire documents, since [link node_document] is not a valid insertion type. The example below provides a workaround.
  * It is possible to copy a subtree as a child of some node inside this subtree, i.e. `node.append_copy(node.parent().parent());`. This is a valid operation, and it results in a clone of the subtree in the state before cloning started, i.e. no infinite recursion takes place.
  
  This is an example with one possible implementation of include tags in XML (link:samples/include.cpp[]). It illustrates node cloning and usage of other document modification functions:
  
negative.code: 
  All of the above operations have the same semantics as that of `std::vector`: the iterators are random-access, all of the above operations are constant time, and accessing the element at index that is greater or equal than the set size results in undefined behavior. You can use both iterator-based and index-based access for iteration, however the iterator-based one can be faster.
  
  [[xpath_node_set::type]][[xpath_node_set::type_unsorted]][[xpath_node_set::type_sorted]][[xpath_node_set::type_sorted_reverse]][[xpath_node_set::sort]]
  The order of iteration depends on the order of nodes inside the set; the order can be queried via the following function:
  
  [source]
  