2. Boost Json Translation (zh_Hans)
3. Doc / Pages / Io / Parsing (adoc)
4. English
5. Zen

47 :190
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Memory consumption per I/O cycle is bounded 43/10000 · 43
48 :191
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Jitter, unfairness, and latency is reduced 42/10000 · 42
49 :192
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Less total memory is required to process the full input 55/10000 · 55
50 :194
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To use the <<ref_stream_parser>>, declare an instance. Then call <<ref_stream_parser_write>> zero or more times with successive buffers representing the input JSON. When there are no more buffers, call <<ref_stream_parser_finish>>. The function <<ref_stream_parser_done>> returns `true` after a successful call to `write` or `finish` if parsing is complete. 357/10000 · 357
51 :200
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the following example a JSON text is parsed from standard input a line at a time. Error codes are used instead. The function <<ref_stream_parser_finish>> is used to indicate the end of the input: 198/10000 · 198
52 :204
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This example will break, if comments are enabled, because of 60/10000 · 60
53 :205
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `std::getline` use (see the warning in <<non_standard_json>> section). 70/10000 · 70
54 :212
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can complicate the example further by extracting _several_ JSON values from the sequence of lines. 101/10000 · 101
55 :220
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Controlling Memory 18/10000 · 18
56 :221
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — After default construction, or after <<ref_stream_parser_reset>> is called with no arguments, the <<ref_value>> produced after a successful parse operation uses the default memory resource. To use a different memory resource, call `reset` with the resource to use. Here we use a <<ref_monotonic_resource>>, which is optimized for parsing but not subsequent modification: 370/10000 · 370
57 :232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To achieve performance and memory efficiency, the parser uses a temporary storage area to hold intermediate results. This storage is reused when parsing more than one JSON text, reducing the total number of calls to allocate memory and thus improving performance. Upon construction, the memory resource used to perform allocations for this temporary storage area may be specified. Otherwise, the default memory resource is used. In addition to a memory resource, the parser can make use of a caller-owned buffer for temporary storage. This can help avoid dynamic allocations for small inputs. The following example uses a four kilobyte temporary buffer for the parser, and falls back to the default memory resource if needed: 725/10000 · 725
58 :248
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Avoiding Dynamic Allocations 28/10000 · 28
59 :249
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Through careful specification of buffers and memory resources, it is possible to eliminate all dynamic allocation completely when parsing JSON, for the case where the entire JSON text is available in a single character buffer, as shown here: 241/10000 · 241
60 :259
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Custom Parsers 14/10000 · 14
61 :260
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Users who wish to implement custom parsing strategies may create their own handler to use with an instance of <<ref_basic_parser>>. The handler implements the function signatures required by SAX event interface. In <<examples_validate>> example we define the "null" parser, which throws out the parsed results, to use in the implementation of a function that determines if a JSON text is valid. 394/10000 · 394
The translation has come to an end.