This doesn't require any implementation changes, as the existing support
for C++11 ranged for loops automatically makes nodes and node/attribute
range objects work as C++20 ranges.
Fixes#613.
parse_merge_pcdata expects to find node_pcdata nodes which aren't
present when parse_embed_pcdata is active. For now we mention this in
the documentation; changing this is possible in the future, but carries
a small performance penalty so it requires a specific use case.
Fixes#600
pugixml currently unconditionally accepts documents with multiple
top-level element nodes in absence of parse_fragment. This is an
unfortunate omission; while it can be corrected, it will result in
regressions for some users, and it's trivial to perform the validity
check after the parse is done.
Because of this, for now we're just going to amend documentation here to
both highlight this in the W3C Conformance section, but also to more
strongly push users into realizing that there's just a single document
element (normally).
We might decide to change the behavior here to prohibit such documents
by default in the future, but for now a documentation change seems like
a better tradeoff.
Fixes#337
This change adds format_attribute_single_quote flag that uses single quotes (`'`) instead of double quotes (`"`) for formatting attribute values.
Internal quotation marks are escaped using `"` and `'`.
This may or may not make it more clear that pugixml.cpp has to be
compiled - either as one of the projects or as a standalone project via
CMake et al - for it to work by default.
Fixes#256.
This is implicitly true due to the following section, but that was
written before C++11 so this does deserve a special mention in ranged
for section as well.
Fixes#210.
Mention ubsan fixes; these fixes probably fix compact mode on some
64-bit architecture where unaligned pointer reads aren't valid as well
but it's probably not very relevant...
It has always been the case that pugixml does not perform Unicode
validation or name/tag Unicode character class validation, but it wasn't
very obvious from documentation.
Fixes#162
We support Latin-1 and automatically detect it by parsing the encoding
from document declaration; both of these were omitted from the
description of the automatic detection.
Additionally, the description has been rewritten to be more concise and
a bit more abstract - there's no need to specify the algorithm precisely
here.
Fixes#158.
