Document Object Model(DOM) is an in-memory representation of JSON for query and manipulation. The basic usage of DOM is described in Tutorial. This section will describe some details and more advanced usages.
In the tutorial,
Document was used. Similarly to
std::string, these are actually
typedef of template classes:
User can customize these template parameters.
Encoding parameter specifies the encoding of JSON String value in memory. Possible options are
UTF32. Note that, these 3 types are also template class.
UTF8<char>, which means using char to store the characters. You may refer to Encoding for details.
Suppose a Windows application would query localization strings stored in JSON files. Unicode-enabled functions in Windows use UTF-16 (wide character) encoding. No matter what encoding was used in JSON files, we can store the strings in UTF-16 in memory.
Allocator defines which allocator class is used when allocating/deallocating memory for
Document owns, or references to an
Allocator instance. On the other hand,
Value does not do so, in order to reduce memory consumption.
The default allocator used in
MemoryPoolAllocator. This allocator actually allocate memory sequentially, and cannot deallocate one by one. This is very suitable when parsing a JSON into a DOM tree.
Another allocator is
CrtAllocator, of which CRT is short for C RunTime library. This allocator simply calls the standard
free(). When there is a lot of add and remove operations, this allocator may be preferred. But this allocator is far less efficient than
Document provides several functions for parsing. In below, (1) is the fundamental function, while the others are helpers which call (1).
parseFlags are combination of the following bit-flags:
|No flag is set.|
|Default parse flags. It is equal to macro |
|Validate encoding of JSON strings.|
|Iterative(constant complexity in terms of function call stack size) parsing.|
|After parsing a complete JSON root from stream, stop further processing the rest of stream. When this flag is used, parser will not generate |
|Parse number in full precision (slower). If this flag is not set, the normal precision (faster) is used. Normal precision has maximum 3 ULP error.|
|Allow one-line |
|Parse numerical type values as strings.|
|Allow trailing commas at the end of objects and arrays (relaxed JSON syntax).|
|Allow parsing |
By using a non-type template parameter, instead of a function parameter, C++ compiler can generate code which is optimized for specified combinations, improving speed, and reducing code size (if only using a single specialization). The downside is the flags needed to be determined in compile-time.
SourceEncoding parameter defines what encoding is in the stream. This can be differed to the
Encoding of the
Document. See Transcoding and Validation section for details.
InputStream is type of input stream.
When the parse processing succeeded, the
Document contains the parse results. When there is an error, the original DOM is unchanged. And the error state of parsing can be obtained by
ParseErrorCode GetParseError() and
|Parse Error Code||Description|
|The document is empty.|
|The document root must not follow by other values.|
|Missing a name for object member.|
|Missing a colon after a name of object member.|
|Missing a comma or |
|Missing a comma or |
|Incorrect hex digit after |
|The surrogate pair in string is invalid.|
|Invalid escape character in string.|
|Missing a closing quotation mark in string.|
|Invalid encoding in string.|
|Number too big to be stored in |
|Miss fraction part in number.|
|Miss exponent in number.|
The offset of error is defined as the character number from beginning of stream. Currently RapidJSON does not keep track of line number.
To get an error message, RapidJSON provided a English messages in
rapidjson/error/en.h. User can customize it for other locales, or use a custom localization system.
Here shows an example of parse error handling.
In situ ... is a Latin phrase that translates literally to "on site" or "in position". It means "locally", "on site", "on the premises" or "in place" to describe an event where it takes place, and is used in many different contexts. ... (In computer science) An algorithm is said to be an in situ algorithm, or in-place algorithm, if the extra amount of memory required to execute the algorithm is O(1), that is, does not exceed a constant no matter how large the input. For example, heapsort is an in situ sorting algorithm.
In normal parsing process, a large overhead is to decode JSON strings and copy them to other buffers. In situ parsing decodes those JSON string at the place where it is stored. It is possible in JSON because the length of decoded string is always shorter than or equal to the one in JSON. In this context, decoding a JSON string means to process the escapes, such as
"\\u1234", etc., and add a null terminator (`'\0'`)at the end of string.
The following diagrams compare normal and in situ parsing. The JSON string values contain pointers to the decoded string.
In normal parsing, the decoded string are copied to freshly allocated buffers.
"\\\\n" (2 characters) is decoded as
"\\n" (1 character).
"\\\\u0073" (6 characters) is decoded as
"s" (1 character).
In situ parsing just modified the original JSON. Updated characters are highlighted in the diagram. If the JSON string does not contain escape character, such as
"msg", the parsing process merely replace the closing double quotation mark with a null character.
Since in situ parsing modify the input, the parsing API needs
char* instead of
The JSON strings are marked as const-string. But they may not be really "constant". The life cycle of it depends on the JSON buffer.
In situ parsing minimizes allocation overheads and memory copying. Generally this improves cache coherence, which is an important factor of performance in modern computer.
There are some limitations of in situ parsing:
In situ parsing is mostly suitable for short-term JSON that only need to be processed once, and then be released from memory. In practice, these situation is very common, for example, deserializing JSON to C++ objects, processing web requests represented in JSON, etc.
RapidJSON supports conversion between Unicode formats (officially termed UCS Transformation Format) internally. During DOM parsing, the source encoding of the stream can be different from the encoding of the DOM. For example, the source stream contains a UTF-8 JSON, while the DOM is using UTF-16 encoding. There is an example code in EncodedInputStream.
When writing a JSON from DOM to output stream, transcoding can also be used. An example is in EncodedOutputStream.
During transcoding, the source string is decoded to into Unicode code points, and then the code points are encoded in the target format. During decoding, it will validate the byte sequence in the source string. If it is not a valid sequence, the parser will be stopped with
When the source encoding of stream is the same as encoding of DOM, by default, the parser will not validate the sequence. User may use
kParseValidateEncodingFlag to force validation.
Some techniques about using DOM API is discussed here.
In RapidJSON, stringifying a DOM with
Writer may be look a little bit weired.
Value::Accept() is responsible for publishing SAX events about the value to the handler. With this design,
Writer are decoupled.
Value can generate SAX events, and
Writer can handle those events.
User may create custom handlers for transforming the DOM into other formats. For example, a handler which converts the DOM into XML.
For more about SAX events and handler, please refer to SAX.
Some applications may try to avoid memory allocations whenever possible.
MemoryPoolAllocator can support this by letting user to provide a buffer. The buffer can be on the program stack, or a "scratch buffer" which is statically allocated (a static/global array) for storing temporary data.
MemoryPoolAllocator will use the user buffer to satisfy allocations. When the user buffer is used up, it will allocate a chunk of memory from the base allocator (by default the
Here is an example of using stack memory. The first allocator is for storing values, while the second allocator is for storing temporary data during parsing.
If the total size of allocation is less than 4096+1024 bytes during parsing, this code does not invoke any heap allocation (via
malloc()) at all.
User can query the current memory consumption in bytes via
MemoryPoolAllocator::Size(). And then user can determine a suitable size of user buffer.