diff --git a/array__iterator_8h_source.html b/array__iterator_8h_source.html index e9bf26436..5b0cd6480 100644 --- a/array__iterator_8h_source.html +++ b/array__iterator_8h_source.html @@ -162,7 +162,7 @@ $(document).ready(function(){initNavTree('array__iterator_8h_source.html',''); i
Definition at line 166 of file array-inl.h.
+Definition at line 219 of file array-inl.h.
+ + + + +
+
|
+ +inlinenoexcept | +
Get the value associated with the given JSON path.
+Right now we are only supporting a subset of json path that is easily convertible to json pointer.
+Definition at line 213 of file array-inl.h.
Iterator marking current position.
iter.is_alive() == false indicates iteration is complete.
-Definition at line 164 of file array.h.
+Definition at line 177 of file array.h.
diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.js b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.js index 5cf9bc489..341dccab6 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.js +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.js @@ -3,6 +3,7 @@ var classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_ [ "array", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#a8cc89dada9999c2ecc319954cc3fc90a", null ], [ "array", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#a240a8118a5b6f76962425134cc284764", null ], [ "at", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#a1c97143f7637414d737d58daeec2eb84", null ], + [ "at_path", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#aa9ec8526ef892cb3766faccf1a674e03", null ], [ "at_pointer", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#a73c2fc4db0c0b4083fafe706412d3b26", null ], [ "begin", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#a8cb4bf0ca1890a4a3c86f69be40f17f2", null ], [ "consume", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1array.html#a96aeba1fb4eac299260937b78e346ee8", null ], diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document-members.html b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document-members.html index be4a86dd9..f2e8061b2 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document-members.html +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document-members.html @@ -96,77 +96,78 @@ $(document).ready(function(){initNavTree('classsimdjson_1_1_s_i_m_d_j_s_o_n___i_Definition at line 213 of file document-inl.h.
@@ -449,7 +452,45 @@ static constexpr at_end() returns false, then there may be trailing content. -Definition at line 47 of file document-inl.h.
+Definition at line 49 of file document-inl.h.
+ + + + +
+
|
+ +noexcept | +
Get the value associated with the given JSON path.
+Right now we are only supporting a subset of json path that is easily convertible to json pointer.
+Definition at line 312 of file document-inl.h.
Definition at line 294 of file document-inl.h.
@@ -523,7 +564,7 @@ static constexpr Definition at line 215 of file document-inl.h. +Definition at line 217 of file document-inl.h.
@@ -553,7 +594,7 @@ static constexpr Definition at line 197 of file document-inl.h. +Definition at line 199 of file document-inl.h.
@@ -584,7 +625,7 @@ static constexpr Definition at line 204 of file document-inl.h. +Definition at line 206 of file document-inl.h.
@@ -614,7 +655,7 @@ static constexpr Definition at line 43 of file document-inl.h. +Definition at line 45 of file document-inl.h.
@@ -644,7 +685,7 @@ static constexpr Definition at line 218 of file document-inl.h. +Definition at line 220 of file document-inl.h.
@@ -691,7 +732,7 @@ static constexprDefinition at line 222 of file document-inl.h.
+Definition at line 224 of file document-inl.h.
@@ -733,7 +774,7 @@ static constexprDefinition at line 228 of file document-inl.h.
+Definition at line 230 of file document-inl.h.
@@ -842,7 +883,7 @@ SUCCESS If the parse succeeded and the out parameter was set to the value.Definition at line 103 of file document-inl.h.
+Definition at line 105 of file document-inl.h.
@@ -874,7 +915,7 @@ INCORRECT_TYPE If the JSON value is not an array.Definition at line 151 of file document-inl.h.
+Definition at line 153 of file document-inl.h.
@@ -906,7 +947,7 @@ INCORRECT_TYPE if the JSON value is not true or false.Definition at line 132 of file document-inl.h.
+Definition at line 134 of file document-inl.h.
@@ -938,7 +979,7 @@ INCORRECT_TYPE If the JSON value is not a valid floating-point number. INCORRECT_TYPE If the JSON value is not a valid floating-point number. -Definition at line 135 of file document-inl.h.
+Definition at line 137 of file document-inl.h.
@@ -970,7 +1011,7 @@ INCORRECT_TYPE If the JSON value is not a valid floating-point number. INCORRECT_TYPE If the JSON value is not a 64-bit integer. -Definition at line 126 of file document-inl.h.
+Definition at line 128 of file document-inl.h.
@@ -1002,7 +1043,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.Definition at line 129 of file document-inl.h.
+Definition at line 131 of file document-inl.h.
@@ -1036,7 +1077,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.Otherwise, number.get_number_type() has value number_type::floating_point_number and we have a binary64 number. You can recover the value by calling number.get_double() and you have that number.is_double() is true.
You must check the type before accessing the value: it is an error to call "get_int64()" when number.get_number_type() is not number_type::signed_integer and when number.is_int64() is false.
-Definition at line 282 of file document-inl.h.
+Definition at line 284 of file document-inl.h.
@@ -1070,7 +1111,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.This function requires processing the number string, but it is expected to be faster than get_number().get_number_type() because it is does not parse the number value.
Definition at line 278 of file document-inl.h.
+Definition at line 280 of file document-inl.h.
@@ -1102,7 +1143,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.Definition at line 107 of file document-inl.h.
+Definition at line 109 of file document-inl.h.
@@ -1136,7 +1177,7 @@ INCORRECT_TYPE If the JSON value is not an object.Definition at line 148 of file document-inl.h.
+Definition at line 150 of file document-inl.h.
@@ -1177,7 +1218,7 @@ INCORRECT_TYPE if the JSON value is not a string.Definition at line 138 of file document-inl.h.
+Definition at line 140 of file document-inl.h.
@@ -1223,7 +1264,7 @@ template<typename string_type >Performance: This method may be slower than get_string() or get_string(bool) because it may need to allocate memory. We recommend you avoid allocating an std::string unless you need to.
Definition at line 142 of file document-inl.h.
+Definition at line 144 of file document-inl.h.
@@ -1257,7 +1298,7 @@ template<typename string_type > INCORRECT_TYPE If the JSON value is not a 64-bit unsigned integer.We want to disallow trailing content. Thus, in several implementations below, we pass a 'true' parameter value to a get_root_value_iterator() method: this indicates that we disallow trailing content.
-Definition at line 120 of file document-inl.h.
+Definition at line 122 of file document-inl.h.
@@ -1289,7 +1330,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit unsigned integer.Definition at line 123 of file document-inl.h.
+Definition at line 125 of file document-inl.h.
@@ -1322,7 +1363,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit unsigned integer.Definition at line 68 of file document-inl.h.
+Definition at line 70 of file document-inl.h.
@@ -1356,7 +1397,7 @@ SCALAR_DOCUMENT_AS_VALUE error is the document is a scalar (see INCORRECT_TYPE if the JSON value is not a string. -Definition at line 145 of file document-inl.h.
+Definition at line 147 of file document-inl.h.
@@ -1386,7 +1427,7 @@ INCORRECT_TYPE if the JSON value is not a string.Some unrecoverable error conditions may render the document instance unusable.
The is_alive() method returns true when the document is still suitable.
-Definition at line 52 of file document-inl.h.
+Definition at line 54 of file document-inl.h.
@@ -1417,7 +1458,7 @@ INCORRECT_TYPE if the JSON value is not a string.Note that this requires to partially parse the number string. If the value is determined to be an integer, it may still not parse properly as an integer in subsequent steps (e.g., it might overflow).
Definition at line 274 of file document-inl.h.
+Definition at line 276 of file document-inl.h.
@@ -1447,7 +1488,7 @@ INCORRECT_TYPE if the JSON value is not a string.Checks whether the document is a negative number.
Definition at line 270 of file document-inl.h.
+Definition at line 272 of file document-inl.h.
@@ -1480,7 +1521,7 @@ INCORRECT_TYPE if the JSON value is not a string.Definition at line 154 of file document-inl.h.
+Definition at line 156 of file document-inl.h.
@@ -1511,7 +1552,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'.Returns false when there it is an array or object.
Definition at line 263 of file document-inl.h.
+Definition at line 265 of file document-inl.h.
@@ -1547,7 +1588,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 186 of file document-inl.h.
+Definition at line 188 of file document-inl.h.
@@ -1583,7 +1624,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 193 of file document-inl.h.
+Definition at line 195 of file document-inl.h.
@@ -1619,7 +1660,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 190 of file document-inl.h.
+Definition at line 192 of file document-inl.h.
@@ -1655,7 +1696,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 189 of file document-inl.h.
+Definition at line 191 of file document-inl.h.
@@ -1691,7 +1732,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 187 of file document-inl.h.
+Definition at line 189 of file document-inl.h.
@@ -1729,7 +1770,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 192 of file document-inl.h.
+Definition at line 194 of file document-inl.h.
@@ -1766,7 +1807,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 191 of file document-inl.h.
+Definition at line 193 of file document-inl.h.
@@ -1802,7 +1843,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 188 of file document-inl.h.
+Definition at line 190 of file document-inl.h.
@@ -1839,7 +1880,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 194 of file document-inl.h.
+Definition at line 196 of file document-inl.h.
@@ -1869,7 +1910,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'.Consumes the document and returns a string_view instance corresponding to the document as represented in JSON.
It points inside the original byte array containing the JSON document.
-Definition at line 247 of file document-inl.h.
+Definition at line 249 of file document-inl.h.
@@ -1910,7 +1951,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'.Definition at line 287 of file document-inl.h.
+Definition at line 289 of file document-inl.h.
@@ -1940,7 +1981,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'.Reset the iterator inside the document instance so we are pointing back at the beginning of the document, as if it had just been created.
It invalidates all values, objects and arrays that you have created so far (including unescaped strings).
-Definition at line 31 of file document-inl.h.
+Definition at line 33 of file document-inl.h.
@@ -1972,7 +2013,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'.NOTE: If you're only expecting a value to be one type (a typical case), it's generally better to just call .get_double, .get_string, etc. and check for INCORRECT_TYPE (or just let it throw an exception).
@error TAPE_ERROR when the JSON value is a bad token like "}" "," or "alse".
-Definition at line 259 of file document-inl.h.
+Definition at line 261 of file document-inl.h.
diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.js b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.js index 273bc0e05..4d5d7a394 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.js +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.js @@ -6,6 +6,7 @@ var classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_ [ "document", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#a8df43e73a52118b91681a13fc897d098", null ], [ "at", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#a01c6bde0574654dc22ea219c3b3dbf51", null ], [ "at_end", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#ae896ac465551b036763e4465b3a16c7b", null ], + [ "at_path", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#a87b1fb46555fdf69761966e49ffaa9d7", null ], [ "at_pointer", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#a74484485f4a3d8dce5943b0cb60ac815", null ], [ "begin", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#a1a450826deb3ba982c9f0ec6208cb246", null ], [ "consume", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document.html#ac16e0e51de3ce97fbd3fd0b1f947d552", null ], diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference-members.html b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference-members.html index 86a90df2d..8243b042b 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference-members.html +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference-members.html @@ -95,60 +95,61 @@ $(document).ready(function(){initNavTree('classsimdjson_1_1_s_i_m_d_j_s_o_n___i_This is the complete list of members for simdjson::SIMDJSON_IMPLEMENTATION::ondemand::document_reference, including all inherited members.
A document_reference is a thin wrapper around a document reference instance.
-Definition at line 639 of file document.h.
+Definition at line 653 of file document.h.
However, for streams of JSON documents, we want to be able to start from "321" "321" "321" and parse it successfully as a stream of JSON documents, calling get_uint64_in_string() successfully each time.
To achieve this result, we pass a 'false' to a get_root_value_iterator() method: this indicates that we allow trailing content.
-Definition at line 600 of file document-inl.h.
+Definition at line 623 of file document-inl.h.
diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.js b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.js index 2d82dad3b..b10f0699c 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.js +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.js @@ -4,6 +4,7 @@ var classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_ [ "document_reference", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#a9d1ddeb339540ee9c6f00b9061f5e908", null ], [ "document_reference", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#a15bc891896726595062910787cd83ca0", null ], [ "at", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#ae7397a55b94d369ace8aff2913ed2467", null ], + [ "at_path", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#a3376bfa954029256f1482657eacfc4db", null ], [ "at_pointer", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#a8645c724ff217f11d09a69a3eb32355b", null ], [ "begin", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#ab6b572642eb8d84f12a32d881499011d", null ], [ "count_elements", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference.html#ac18dc949283225dd5ae7e0a6e74b4563", null ], diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object-members.html b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object-members.html index 753ea6707..39e51cc38 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object-members.html +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object-members.html @@ -94,28 +94,29 @@ $(document).ready(function(){initNavTree('classsimdjson_1_1_s_i_m_d_j_s_o_n___i_This is the complete list of members for simdjson::SIMDJSON_IMPLEMENTATION::ondemand::object, including all inherited members.
+
|
+ +inlinenoexcept | +
Get the value associated with the given JSON path.
+Right now we are only supporting a subset of json path that is easily convertible to json pointer.
+Definition at line 167 of file object-inl.h.
+ +To check that an object is empty, it is more performant to use the is_empty() method.
Performance hint: You should only call count_fields() as a last resort as it may require scanning the document twice or more.
-Definition at line 167 of file object-inl.h.
+Definition at line 175 of file object-inl.h.
@@ -437,7 +478,7 @@ value_iteratorThis method scans the beginning of the object and checks whether the object is empty.
The runtime complexity is constant time. After calling this function, if successful, the object is 'rewinded' at its beginning as if it had never been accessed. If the JSON is malformed (e.g., there is a missing comma), then an error is returned and it is no longer safe to continue.
-Definition at line 179 of file object-inl.h.
+Definition at line 187 of file object-inl.h.
@@ -498,7 +539,7 @@ value_iteratorYou should still consume values only once even if you can iterate through the object more than once. If you unescape a string within the object more than once, you have unsafe code. Note that rewinding an object means that you may need to reparse it anew: it is not a free operation.
Definition at line 186 of file object-inl.h.
+Definition at line 194 of file object-inl.h.
diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.js b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.js index 901d8667d..f350df7d9 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.js +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.js @@ -2,6 +2,7 @@ var classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_ [ [ "object", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.html#a034b27d7ff75832a574c2069af267111", null ], [ "object", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.html#a6724eb440d3fb40018a9a47c715352ed", null ], + [ "at_path", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.html#ae1bb196ae5f2aeabd8d95accdcd73498", null ], [ "at_pointer", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.html#ae3d80f8e7f31c319fe6ee09c0860df83", null ], [ "begin", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.html#aeb4a70edd1808f36210460ed410e8dae", null ], [ "consume", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object.html#add102ee85423a75e22e4d7ca9a3eaacd", null ], diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1parser.html b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1parser.html index 7bd172fe0..240bccce6 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1parser.html +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1parser.html @@ -304,16 +304,16 @@ simdjson_inline voidStart iterating an on-demand JSON document.
ondemand::parser parser; document doc = parser.iterate(json);
It is expected that the content is a valid UTF-8 file, containing a valid JSON document. Otherwise the iterate method may return an error. In particular, the whole input should be valid: we do not attempt to tolerate incorrect content either before or after a JSON document. If there is a UTF-8 BOM, the parser skips it.
-Calling iterate on an invalid JSON document may not immediately trigger an error. The call to iterate does not parse and validate the whole document.
-Because parsing is done while you iterate, you must keep the JSON buffer around at least as long as the document iteration.
-Only one iteration at a time can happen per parser, and the parser must be kept alive during iteration to ensure intermediate buffers can be accessed. Any document must be destroyed before you call parse() again or destroy the parser.
-The buffer must have at least SIMDJSON_PADDING extra allocated bytes. It does not matter what those bytes are initialized to, as long as they are allocated. These bytes will be read: if you using a sanitizer that verifies that no uninitialized byte is read, then you should initialize the SIMDJSON_PADDING bytes to avoid runtime warnings.
No copy of the input buffer is made.
The function is lazy: it may be that no more than one JSON document at a time is parsed.
The caller is responsabile to ensure that the input string data remains unchanged and is not deleted during the loop.
-The buffer must contain a series of one or more JSON documents, concatenated into a single buffer, separated by ASCII whitespace. It effectively parses until it has a fully valid document, then starts parsing the next document at that point. (It does this with more parallelism and lookahead than you might think, though.)
documents that consist of an object or array may omit the whitespace between them, concatenating with no separator. Documents that consist of a single primitive (i.e. documents that are not arrays or objects) MUST be separated with ASCII whitespace.
The characters inside a JSON document, and between JSON documents, must be valid Unicode (UTF-8). If there is a UTF-8 BOM, the parser skips it.
The documents must not exceed batch_size bytes (by default 1MB) or they will fail to parse. Setting batch_size to excessively large or excessively small values may impact negatively the performance.
-The buffer must have at least SIMDJSON_PADDING extra allocated bytes. It does not matter what those bytes are initialized to, as long as they are allocated. These bytes will be read: if you using a sanitizer that verifies that no uninitialized byte is read, then you should initialize the SIMDJSON_PADDING bytes to avoid runtime warnings.
-When compiled with SIMDJSON_THREADS_ENABLED, this method will use a single thread under the hood to do some lookahead.
-If the parser's current capacity is less than batch_size, it will allocate enough capacity to handle it (up to max_capacity).
to a user-provided buffer. The result must be valid UTF-8. The provided pointer is advanced to the end of the string by reference, and a string_view instance is returned. You can ensure that your buffer is large enough by allocating a block of memory at least as large as the input JSON plus SIMDJSON_PADDING and then unescape all strings to this one buffer.
This unescape function is a low-level function. If you want a more user-friendly approach, you should avoid raw_json_string instances (e.g., by calling unescaped_key() instead of key() or get_string() instead of get_raw_json_string()).
-The string_view is only valid as long as the bytes in dst.
to a user-provided buffer. The result may not be valid UTF-8. See https://simonsapin.github.io/wtf-8/ The provided pointer is advanced to the end of the string by reference, and a string_view instance is returned. You can ensure that your buffer is large enough by allocating a block of memory at least as large as the input JSON plus SIMDJSON_PADDING and then unescape all strings to this one buffer.
This unescape function is a low-level function. If you want a more user-friendly approach, you should avoid raw_json_string instances (e.g., by calling unescaped_key() instead of key() or get_string() instead of get_raw_json_string()).
-The string_view is only valid as long as the bytes in dst.
This is the complete list of members for simdjson::SIMDJSON_IMPLEMENTATION::ondemand::value, including all inherited members.
Definition at line 149 of file value-inl.h.
+Definition at line 151 of file value-inl.h.
+ + + + +
+
|
+ +noexcept | +
Get the value associated with the given JSON path.
+Right now we are only supporting a subset of json path that is easily convertible to json pointer.
+Definition at line 248 of file value-inl.h.
Definition at line 232 of file value-inl.h.
+Definition at line 234 of file value-inl.h.
@@ -431,7 +472,7 @@ value_iteratorPart of the std::iterable interface.
Definition at line 126 of file value-inl.h.
+Definition at line 128 of file value-inl.h.
@@ -462,7 +503,7 @@ value_iteratorThe count_elements method should always be called before you have begun iterating through the array: it is expected that you are pointing at the beginning of the array. The runtime complexity is linear in the size of the array. After calling this function, if successful, the array is 'rewinded' at its beginning as if it had never been accessed. If the JSON is malformed (e.g., there is a missing comma), then an error is returned and it is no longer safe to continue.
Performance hint: You should only call count_elements() as a last resort as it may require scanning the document twice or more.
-Definition at line 132 of file value-inl.h.
+Definition at line 134 of file value-inl.h.
@@ -494,7 +535,7 @@ value_iteratorTo check that an object is empty, it is more performant to use the is_empty() method on the object instance.
Performance hint: You should only call count_fields() as a last resort as it may require scanning the document twice or more.
-Definition at line 142 of file value-inl.h.
+Definition at line 144 of file value-inl.h.
@@ -524,7 +565,7 @@ value_iteratorReturns the current depth in the document if in bounds.
E.g., 0 = finished with document 1 = document root value (could be [ or {, not yet known) 2 = , or } inside root array/object 3 = key or value inside root array/object.
-Definition at line 228 of file value-inl.h.
+Definition at line 230 of file value-inl.h.
@@ -554,7 +595,7 @@ value_iteratorSentinel representing the end of the array.
Part of the std::iterable interface.
-Definition at line 129 of file value-inl.h.
+Definition at line 131 of file value-inl.h.
@@ -601,7 +642,7 @@ value_iteratorThis is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
-Definition at line 154 of file value-inl.h.
+Definition at line 156 of file value-inl.h.
@@ -643,7 +684,7 @@ value_iteratorThis is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
-Definition at line 161 of file value-inl.h.
+Definition at line 163 of file value-inl.h.
@@ -721,7 +762,7 @@ template<typename T >Definition at line 91 of file value-inl.h.
+Definition at line 93 of file value-inl.h.
@@ -753,7 +794,7 @@ SUCCESS If the parse succeeded and the out parameter was set to the value.Definition at line 30 of file value-inl.h.
+Definition at line 32 of file value-inl.h.
@@ -785,7 +826,7 @@ INCORRECT_TYPE If the JSON value is not an array.Definition at line 75 of file value-inl.h.
+Definition at line 77 of file value-inl.h.
@@ -817,7 +858,7 @@ INCORRECT_TYPE if the JSON value is not true or false.Definition at line 57 of file value-inl.h.
+Definition at line 59 of file value-inl.h.
@@ -849,7 +890,7 @@ INCORRECT_TYPE If the JSON value is not a valid floating-point number. INCORRECT_TYPE If the JSON value is not a valid floating-point number. -Definition at line 60 of file value-inl.h.
+Definition at line 62 of file value-inl.h.
@@ -881,7 +922,7 @@ INCORRECT_TYPE If the JSON value is not a valid floating-point number. INCORRECT_TYPE If the JSON value is not a 64-bit integer. -Definition at line 69 of file value-inl.h.
+Definition at line 71 of file value-inl.h.
@@ -913,7 +954,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.Definition at line 72 of file value-inl.h.
+Definition at line 74 of file value-inl.h.
@@ -948,7 +989,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.You must check the type before accessing the value: it is an error to call "get_int64()" when number.get_number_type() is not number_type::signed_integer and when number.is_int64() is false.
Performance note: this is designed with performance in mind. When calling 'get_number()', you scan the number string only once, determining efficiently the type and storing it in an efficient manner.
-Definition at line 196 of file value-inl.h.
+Definition at line 198 of file value-inl.h.
@@ -982,7 +1023,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.This function requires processing the number string, but it is expected to be faster than get_number().get_number_type() because it is does not parse the number value.
Definition at line 193 of file value-inl.h.
+Definition at line 195 of file value-inl.h.
@@ -1014,7 +1055,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit integer.Definition at line 33 of file value-inl.h.
+Definition at line 35 of file value-inl.h.
@@ -1048,7 +1089,7 @@ INCORRECT_TYPE If the JSON value is not an object.Definition at line 44 of file value-inl.h.
+Definition at line 46 of file value-inl.h.
@@ -1084,7 +1125,7 @@ INCORRECT_TYPE if the JSON value is not a string.Definition at line 47 of file value-inl.h.
+Definition at line 49 of file value-inl.h.
@@ -1130,7 +1171,7 @@ template<typename string_type >Performance: This method may be slower than get_string() or get_string(bool) because it may need to allocate memory. We recommend you avoid allocating an std::string unless you need to.
Definition at line 51 of file value-inl.h.
+Definition at line 53 of file value-inl.h.
@@ -1162,7 +1203,7 @@ template<typename string_type >Definition at line 63 of file value-inl.h.
+Definition at line 65 of file value-inl.h.
@@ -1194,7 +1235,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit unsigned integer.Definition at line 66 of file value-inl.h.
+Definition at line 68 of file value-inl.h.
@@ -1228,7 +1269,7 @@ INCORRECT_TYPE If the JSON value is not a 64-bit unsigned integer.Definition at line 54 of file value-inl.h.
+Definition at line 56 of file value-inl.h.
@@ -1260,7 +1301,7 @@ INCORRECT_TYPE if the JSON value is not a string.Performance note: if you call this function systematically before parsing a number, you may have fallen for a performance anti-pattern.
Definition at line 190 of file value-inl.h.
+Definition at line 192 of file value-inl.h.
@@ -1290,7 +1331,7 @@ INCORRECT_TYPE if the JSON value is not a string.Checks whether the value is a negative number.
Definition at line 186 of file value-inl.h.
+Definition at line 188 of file value-inl.h.
@@ -1323,7 +1364,7 @@ INCORRECT_TYPE if the JSON value is not a string.Definition at line 78 of file value-inl.h.
+Definition at line 80 of file value-inl.h.
@@ -1354,7 +1395,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'.Returns false when there it is an array or object.
Definition at line 179 of file value-inl.h.
+Definition at line 181 of file value-inl.h.
@@ -1390,7 +1431,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 100 of file value-inl.h.
+Definition at line 102 of file value-inl.h.
@@ -1426,7 +1467,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 121 of file value-inl.h.
+Definition at line 123 of file value-inl.h.
@@ -1462,7 +1503,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 112 of file value-inl.h.
+Definition at line 114 of file value-inl.h.
@@ -1498,7 +1539,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 109 of file value-inl.h.
+Definition at line 111 of file value-inl.h.
@@ -1534,7 +1575,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 103 of file value-inl.h.
+Definition at line 105 of file value-inl.h.
@@ -1572,7 +1613,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 118 of file value-inl.h.
+Definition at line 120 of file value-inl.h.
@@ -1610,7 +1651,7 @@ INCORRECT_TYPE If the JSON value begins with 'n' and is not 'null'. -Definition at line 115 of file value-inl.h.
+Definition at line 117 of file value-inl.h.
@@ -1640,7 +1681,7 @@ template<class T >The programmer is responsible for providing an implementation of get<T> for the type T.
Definition at line 97 of file value-inl.h.
+Definition at line 99 of file value-inl.h.
@@ -1676,7 +1717,7 @@ template<class T > -Definition at line 106 of file value-inl.h.
+Definition at line 108 of file value-inl.h.
@@ -1706,7 +1747,7 @@ template<class T >Get a string_view pointing at this value in the JSON document.
If this element is an array or an object, it consumes the array or the object and returns a string_view instance corresponding to the array as represented in JSON. It points inside the original document. If this element is a scalar (string, number, Boolean, null), it returns what raw_json_token() would return.
-Definition at line 204 of file value-inl.h.
+Definition at line 206 of file value-inl.h.
@@ -1748,7 +1789,7 @@ template<class T >See also value::raw_json().
-Definition at line 200 of file value-inl.h.
+Definition at line 202 of file value-inl.h.
@@ -1779,7 +1820,7 @@ template<class T >Start a value at the current position.
(It should already be started; this is just a self-documentation method.)
-Definition at line 23 of file value-inl.h.
+Definition at line 25 of file value-inl.h.
@@ -1811,7 +1852,7 @@ template<class T >NOTE: If you're only expecting a value to be one type (a typical case), it's generally better to just call .get_double, .get_string, etc. and check for INCORRECT_TYPE (or just let it throw an exception).
Definition at line 175 of file value-inl.h.
+Definition at line 177 of file value-inl.h.
diff --git a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.js b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.js index 88db77ae1..78ff7f28f 100644 --- a/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.js +++ b/classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.js @@ -3,6 +3,7 @@ var classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_ [ "value", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#ab96f6c19a1866863a110e8bcc93e0392", null ], [ "value", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#a7188b9843c2b3b3050c54b52d5b6886f", null ], [ "at", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#acc369e813e7cf4a97564bb0d85f76db3", null ], + [ "at_path", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#a6f6c6d98a3605c8e04cad16fce05c16c", null ], [ "at_pointer", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#aadd2f646a3231d407948bf5f3da46528", null ], [ "begin", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#a88d1cdc3124965d707754af4fcfae7f9", null ], [ "count_elements", "classsimdjson_1_1_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value.html#a481e2b0b216d29038ddca3242a7047ad", null ], diff --git a/classsimdjson_1_1dom_1_1parser.html b/classsimdjson_1_1dom_1_1parser.html index 0aab5f6ce..a1c3a8dcb 100644 --- a/classsimdjson_1_1dom_1_1parser.html +++ b/classsimdjson_1_1dom_1_1parser.html @@ -404,11 +404,11 @@ simdjson_inline simLoad a JSON document from a file and return a reference to it.
dom::parser parser; const element doc = parser.load("jsonexamples/twitter.json");
The function is eager: the file's content is loaded in memory inside the parser instance and immediately parsed. The file can be deleted after the parser.load call.
The JSON document still lives in the parser: this is the most efficient way to parse JSON documents because it reuses the same buffers, but you must use the document before you destroy the parser or call parse() again.
Moving the parser instance is safe, but it invalidates the element instances. You may store the parser instance without moving it by wrapping it inside an unique_ptr instance like so: std::unique_ptr<dom::parser> parser(new dom::parser{});.
If the parser's current capacity is less than the file length, it will allocate enough capacity to handle it (up to max_capacity).
It is similar to the function load except that instead of parsing into the internal document instance associated with the parser, it allows the user to provide a document instance.
dom::parser parser; dom::document doc; element doc_root = parser.load_into_document(doc, "jsonexamples/twitter.json");
The function is eager: the file's content is loaded in memory inside the parser instance and immediately parsed. The file can be deleted after the parser.load_into_document call.
After the call to load_into_document, the parser is no longer needed.
The JSON document lives in the document instance: you must keep the document instance alive while you navigate through it (i.e., used the returned value from load_into_document). You are encourage to reuse the document instance many times with new data to avoid reallocations:
@@ -531,20 +531,20 @@ IMPORTANT: Document LifetimeThe file is loaded in memory and can be safely deleted after the parser.load_many(path) function has returned. The memory is held by the parser instance.
The function is lazy: it may be that no more than one JSON document at a time is parsed. And, possibly, no document many have been parsed when the parser.load_many(path) function returned.
If there is a UTF-8 BOM, the parser skips it.
-The file must contain a series of one or more JSON documents, concatenated into a single buffer, separated by whitespace. It effectively parses until it has a fully valid document, then starts parsing the next document at that point. (It does this with more parallelism and lookahead than you might think, though.)
Documents that consist of an object or array may omit the whitespace between them, concatenating with no separator. documents that consist of a single primitive (i.e. documents that are not arrays or objects) MUST be separated with whitespace.
The documents must not exceed batch_size bytes (by default 1MB) or they will fail to parse. Setting batch_size to excessively large or excesively small values may impact negatively the performance.
-All errors are returned during iteration: if there is a global error such as memory allocation, it will be yielded as the first result. Iteration always stops after the first error.
As with all other simdjson methods, non-exception error handling is readily available through the same interface, requiring you to check the error before using the document:
dom::parser parser; dom::document_stream docs; auto error = parser.load_many(path).get(docs); if (error) { cerr << error << endl; exit(1); } for (auto doc : docs) { std::string_view title; if ((error = doc["title"].get(title)) { cerr << error << endl; exit(1); } cout << title << endl; }
-When compiled with SIMDJSON_THREADS_ENABLED, this method will use a single thread under the hood to do some lookahead.
-If the parser's current capacity is less than batch_size, it will allocate enough capacity to handle it (up to max_capacity).
Parse a JSON document and return a temporary reference to it.
dom::parser parser; element doc_root = parser.parse(buf, len);
The function eagerly parses the input: the input can be modified and discarded after the parser.parse(buf, len) call has completed.
The JSON document still lives in the parser: this is the most efficient way to parse JSON documents because it reuses the same buffers, but you must use the document before you destroy the parser or call parse() again.
Moving the parser instance is safe, but it invalidates the element instances. You may store the parser instance without moving it by wrapping it inside an unique_ptr instance like so: std::unique_ptr<dom::parser> parser(new dom::parser{});.
The buffer must have at least SIMDJSON_PADDING extra allocated bytes. It does not matter what those bytes are initialized to, as long as they are allocated. These bytes will be read: if you using a sanitizer that verifies that no uninitialized byte is read, then you should initialize the SIMDJSON_PADDING bytes to avoid runtime warnings.
If realloc_if_needed is true (the default), it is assumed that the buffer does not have enough padding, and it is copied into an enlarged temporary buffer before parsing. Thus the following is safe:
@@ -716,7 +716,7 @@ REQUIRED: Buffer PaddingIf you set realloc_if_needed to false (e.g., parser.parse(json, json_len, false)), you must provide a buffer with at least SIMDJSON_PADDING extra bytes at the end. The benefit of setting realloc_if_needed to false is that you avoid a temporary memory allocation and a copy.
The padded bytes may be read. It is not important how you initialize these bytes though we recommend a sensible default like null character values or spaces. For example, the following low-level code is safe:
const char *json = R"({"key":"value"})"; const size_t json_len = std::strlen(json); std::unique_ptr<char[]> padded_json_copy{new char[json_len + SIMDJSON_PADDING]}; std::memcpy(padded_json_copy.get(), json, json_len); std::memset(padded_json_copy.get() + json_len, '\0', SIMDJSON_PADDING); simdjson::dom::parser parser; simdjson::dom::element element = parser.parse(padded_json_copy.get(), json_len, false);
-If the parser's current capacity is less than len, it will allocate enough capacity to handle it (up to max_capacity).
It is similar to the function parse except that instead of parsing into the internal document instance associated with the parser, it allows the user to provide a document instance.
dom::parser parser; dom::document doc; element doc_root = parser.parse_into_document(doc, buf, len);
The function eagerly parses the input: the input can be modified and discarded after the parser.parse(buf, len) call has completed.
After the call to parse_into_document, the parser is no longer needed.
The JSON document lives in the document instance: you must keep the document instance alive while you navigate through it (i.e., used the returned value from parse_into_document). You are encourage to reuse the document instance many times with new data to avoid reallocations:
@@ -864,23 +864,23 @@ IMPORTANT: Document LifetimeThe following is safe:
auto json = "[\"temporary data"]"_padded; auto docs = parser.parse_many(json); for (element doc : docs) { cout << std::string(doc["title"]) << endl; }
If there is a UTF-8 BOM, the parser skips it.
-The buffer must contain a series of one or more JSON documents, concatenated into a single buffer, separated by whitespace. It effectively parses until it has a fully valid document, then starts parsing the next document at that point. (It does this with more parallelism and lookahead than you might think, though.)
documents that consist of an object or array may omit the whitespace between them, concatenating with no separator. documents that consist of a single primitive (i.e. documents that are not arrays or objects) MUST be separated with whitespace.
The documents must not exceed batch_size bytes (by default 1MB) or they will fail to parse. Setting batch_size to excessively large or excesively small values may impact negatively the performance.
-All errors are returned during iteration: if there is a global error such as memory allocation, it will be yielded as the first result. Iteration always stops after the first error.
As with all other simdjson methods, non-exception error handling is readily available through the same interface, requiring you to check the error before using the document:
dom::parser parser; dom::document_stream docs; auto error = parser.load_many(path).get(docs); if (error) { cerr << error << endl; exit(1); } for (auto doc : docs) { std::string_view title; if ((error = doc["title"].get(title)) { cerr << error << endl; exit(1); } cout << title << endl; }
-The buffer must have at least SIMDJSON_PADDING extra allocated bytes. It does not matter what those bytes are initialized to, as long as they are allocated. These bytes will be read: if you using a sanitizer that verifies that no uninitialized byte is read, then you should initialize the SIMDJSON_PADDING bytes to avoid runtime warnings.
-When compiled with SIMDJSON_THREADS_ENABLED, this method will use a single thread under the hood to do some lookahead.
-If the parser's current capacity is less than batch_size, it will allocate enough capacity to handle it (up to max_capacity).
![]() |
+
+ simdjson
+ 3.6.4
+
+ Ridiculously Fast JSON
+ |
+
![]() |
+
+ simdjson
+ 3.6.4
+
+ Ridiculously Fast JSON
+ |
+
A JSON Path is a sequence of segments each starting with the '/' character. Within arrays, an integer index allows you to select the indexed node. Within objects, the string value of the key allows you to select the value. If your keys contain the characters '/' or '~', they must be escaped as '~1' and '~0' respectively. An empty JSON Path refers to the whole document.
+A JSON Pointer path is a sequence of segments each starting with the '/' character. Within arrays, a zero-based integer index allows you to select the indexed node. Within objects, the string value of the key allows you to select the value. If your keys contain the characters '/' or '~', they must be escaped as '~1' and '~0' respectively. An empty JSON Pointer Path refers to the whole document.
For multiple JSON pointer queries on a document, one can call at_pointer multiple times.
When the JSON path is the empty string ("") applied to a scalar document (lone string, number, Boolean or null), a SCALAR_DOCUMENT_AS_VALUE error is returned because scalar document cannot be represented as value instances. You can check that a document is a scalar with the method scalar().
When the JSON Pointer Path is the empty string ("") applied to a scalar document (lone string, number, Boolean or null), a SCALAR_DOCUMENT_AS_VALUE error is returned because scalar document cannot be represented as value instances. You can check that a document is a scalar with the method scalar().
The simdjson library now supports a subset of JSON Path through the at_path() method, allowing you to reach further into the document in a single call. The subset of JSON path that is implemented is the subset that is trivially convertible into the JSON Pointer format, using . to access a field and [] to access a specific index.
This implementation relies on at_path() converting its argument to JSON Pointer and then calling at_pointer, which makes use of rewind to reset the parser at the beginning of the document. Hence, it invalidates all previously parsed values, objects and arrays: make sure to consume the values between each call to at_path.
Consider the following example:
+A call to at_path(json_path) can result in any of the errors that are returned by the at_pointer method and if the conversion of json_path to json pointer fails, it will lead to an simdjson::INVALID_JSON_POINTERerror.
Error handing with exception and a single try/catch clause makes the code simple, but it gives you little control over errors. For easier debugging or more robust error handling, you may want to consider our exception-free approach.
The entire simdjson API is usable with and without exceptions. All simdjson APIs that can fail return simdjson_result<T>, which is a <value, error_code> pair. You can retrieve the value with .get() without generating an exception, like so:
The at method can only be called once on an array. It cannot be used to iterate through the values of an array.
This is how the example in "Using the Parsed JSON" could be written using only error code checking (without exceptions):
The simdjson can be build with exceptions entirely disabled. It checks the __cpp_exceptions macro at compile time. Even if exceptions are enabled in your compiler, you may still disable exceptions specifically for simdjson, by setting SIMDJSON_EXCEPTIONS to 0 (false) at compile-time when building the simdjson library. If you are building with CMake, to ensure you don't write any code that uses exceptions, you compile with SIMDJSON_EXCEPTIONS=OFF. For example, if including the project via cmake:
Users more comfortable with an exception flow may choose to directly cast the simdjson_result<T> to the desired type:
Sometimes, it might be helpful to know the current location in the document during iteration. This is especially useful when encountering errors. The current_location() method on a document instances makes it easy to identify common JSON errors. Users can call the current_location() method on a valid document instance to retrieve a const char * pointer to the current location in the document. This method also works even after an error has invalidated the document and the parser (e.g. TAPE_ERROR, INCOMPLETE_ARRAY_OR_OBJECT). When the input was a padding_string or another null-terminated source, then you may use the const char * pointer as a C string. As an example, consider the following example where we used the exception-free simdjson interface:
The current_location() method requires a valid document instance. If the iterate function fails to return a valid document, then you cannot use current_location() to identify the location of an error in the input string. The errors reported by iterate function include EMPTY if no JSON document is detected, UTF8_ERROR if the string is not a valid UTF-8 string, UNESCAPED_CHARS if a string contains control characters that must be escaped and UNCLOSED_STRING if there is an unclosed string in the document. We do not provide location information for these errors.
The parser validates all parsed content, but your code may exhaust the content while not having processed the entire document. Thus, as a final optional step, you may call at_end() on the document instance. If it returns false, then you may conclude that you have trailing content and that your document is not valid JSON. You may then use doc.current_location() to obtain a pointer to the start of the trailing content.
The at_end() method is equivalent to doc.current_location().error() == simdjson::SUCCESS but more convenient.
In some instances, you may need to go through a document more than once. For that purpose, you may call the rewind() method on the document instance. It allows you to restart processing from the beginning without rescanning all of the input data again. It invalidates all values, objects and arrays that you have created so far (including unescaped strings).
In the following example, we print on the screen the number of cars in the JSON input file before printout the data.
@@ -1233,7 +1259,7 @@ RewindingPerformance note: the On Demand front-end does not materialize the parsed numbers and other values. If you are accessing everything twice, you may need to parse them twice. Thus the rewind functionality is best suited for cases where the first pass only scans the structure of the document.
Both arrays and objects have a similar method reset(). It is similar to the document rewind() method, except that it does not rewind the internal string buffer. Thus you should consume values only once even if you can iterate through the array or object more than once. If you unescape a string within an array more than once, you have unsafe code.
When processing large inputs (e.g., in the context of data engineering), engineers commonly serialize data into streams of multiple JSON documents. That is, instead of one large (e.g., 2 GB) JSON document containing multiple records, it is often preferable to write out multiple records as independent JSON documents, to be read one-by-one.
The simdjson library also supports multithreaded JSON streaming through a large file containing many smaller JSON documents in either ndjson or JSON lines format. If your JSON documents all contain arrays or objects, we even support direct file concatenation without whitespace. However, if there is content between your JSON documents, it should be exclusively ASCII white-space characters.
@@ -1291,7 +1317,7 @@ Newline-Delimited JSON (ndjson) and JSON linesIf your documents are large (e.g., larger than a megabyte), then the iterate_many function is maybe ill-suited. It is really meant to support reading efficiently streams of relatively small documents (e.g., a few kilobytes each). If you have larger documents, you should use other functions like iterate.
We also provide some support for comma-separated documents and other advanced features. See iterate_many.md for detailed information and design.
-Though the JSON specification allows for numbers and string values, many engineers choose to integrate the numbers inside strings, e.g., they prefer {"a":"1.9"} to{"a":1.9}. The simdjson library supports parsing valid numbers inside strings which makes it more convenient for people working with those types of documents. This feature is supported through three methods: get_double_in_string, get_int64_in_string and get_uint64_in_string. However, it is important to note that these methods are not substitute to the regular get_double, get_int64 and get_uint64. The usage of the get_*_in_string methods is solely to parse valid JSON numbers inside strings, and so we expect users to call these methods appropriately. In particular, a valid JSON number has no leading and no trailing whitespaces, and the strings "nan", "1e" and "infinity" will not be accepted as valid numbers. As an example, suppose we have the following JSON text:
It is also important to note that when dealing an invalid number inside a string, simdjson will report a NUMBER_ERROR error if the string begins with a number whereas simdjson will report a INCORRECT_TYPE error otherwise.
The *_in_string methods can also be called on a single document instance: e.g., when your document consist solely of a quoted number.
The JSON standard does not offer strongly typed numbers. It suggests that using the binary64 type (double in C++) is a safe choice, but little else. Given the JSON array [1.0,1], it is not specified whether it is an array of two floating-point numbers, two integers, or one floating-point number followed by an integer.
Given an ondemand::value instance, you may ask whether it is a negative value with the is_negative() method. The function is inexpensive.
It is sometimes useful to have access to a raw (unescaped) string: we make available a minimalist raw_json_string data type which contains a pointer inside the string in the original document, right after the quote. It is accessible via get_raw_json_string() on a string instance and returned by the key() method on an object's field instance. It is always optional: replacing get_raw_json_string() with get_string() and key() by unescaped_key() returns an string_view instance of the unescaped string.
You can quickly compare a raw_json_string instance with a target string. You may also unescape the raw_json_string on your own string buffer: parser.unescape(mystr, ptr) advances the provided pointer ptr and returns a string_view instance on the newly serialized string upon success, otherwise it returns an error. When unescaping to your own string buffer, you should ensure that you have sufficient memory space: the total size of the strings plus simdjson::SIMDJSON_PADDING bytes. The following example illustrates how we can unescape JSON string to a user-provided buffer:
If your value is a string, the raw_json_string you with get_raw_json_string() gives you direct access to the unprocessed string. But the simdjson library allows you to have access to the raw underlying JSON more generally, not just for strings.
The simdjson library makes explicit assumptions about types. For examples, numbers must be integers (up to 64-bit integers) or binary64 floating-point numbers. Some users have different needs. For example, some users might want to support big integers. The library makes this possible by providing a raw_json_token method which returns a std::string_view instance containing the value as a string which you may then parse as you see fit.
The simdjson library favours the use of std::string_view instances because it tends to lead to better performance due to causing fewer memory allocations. However, they are cases where you need to store a string result in an std::string instance. You can do so with a templated version of theto_string()method which takes as a parameter a reference to anstd::string`.
You should be mindful of the trade-off: allocating multiple std::string instances can become expensive.
We built simdjson with thread safety in mind.
The simdjson library is single-threaded except for `iterate_many` and `parse_many` which may use secondary threads under their control when the library is compiled with thread support.
We recommend using one parser object per thread. When using the On Demand front-end (our default), you should access the document instances in a single-threaded manner since it acts as an iterator (and is therefore not thread safe).
The CPU detection, which runs the first time parsing is attempted and switches to the fastest parser for your CPU, is transparent and thread-safe.
In a threaded environment, stack space is often limited. Running code like simdjson in debug mode may require hundreds of kilobytes of stack memory. Thus stack overflows are a possibility. We recommend you turn on optimization when working in an environment where stack space is limited. If you must run your code in debug mode, we recommend you configure your system to have more stack space. We discourage you from running production code based on a debug build.
-The simdjson library is fully compliant with the RFC 8259 JSON specification.
The only header file supported by simdjson is simdjson.h. Older versions of simdjson published a number of other include files such as document.h or ParsedJson.h alongside simdjson.h; these headers may be moved or removed in future versions.
Some users like to have example. The following code samples illustrate how to process specific JSON inputs. For simplicity, we do not include full error support: this code would throw exceptions on error.
SIMDJSON_VERBOSE_LOGGING prior to including the simdjson.h header, which enables logging in simdjson. Run your code. It may generate a lot of logging output; adding printouts from your application that show each section may be helpful. The log's output will show step-by-step information on state, buffer pointer position, depth, and key retrieval status. Importantly, unless SIMDJSON_VERBOSE_LOGGING is defined, logging is entirely disabled and thus carries no overhead.The simdjson library offers two distinct approaches on how to access a JSON document. We support a conventional Document-Object-Model (DOM) front-end. In such a scenario, the JSON document is entirely parsed, validated and materialized in memory as the first step. The programmer may then access the parsed data using this in-memory model.
-The simdjson library offers a simple DOM tree API, which you can access by creating a dom::parser and calling the load() method:
During theload or parse calls, neither the input file nor the input string are ever modified. After calling load or parse, the source (either a file or a string) can be safely discarded. All of the JSON data is stored in the parser instance. The parsed document is also immutable in simdjson: you do not modify it by accessing it.
For best performance, a parser instance should be reused over several files: otherwise you will needlessly reallocate memory, an expensive process. It is also possible to avoid entirely memory allocations during parsing when using simdjson. See our performance notes for details.
If you need a lower-level interface, you may call the function parser.parse(const char * p, size_t l) on a pointer p while specifying the length of your input l in bytes. To see how to get the very best performance from a low-level approach, you way want to read our performance notes on this topic (see the Padding and Temporary Copies section).
Once you have an element, you can navigate it with idiomatic C++ iterators, operators and casts.
element.type(). It returns an element_type with values such as simdjson::dom::element_type::ARRAY, simdjson::dom::element_type::OBJECT, simdjson::dom::element_type::INT64, simdjson::dom::element_type::UINT64,simdjson::dom::element_type::DOUBLE, simdjson::dom::element_type::STRING, simdjson::dom::element_type::BOOL or, simdjson::dom::element_type::NULL_VALUE.out << element). You can also request the construction of a minified string version (simdjson::minify(element)) or a prettified string version (simdjson::prettify(element)). Numbers are serialized as 64-bit floating-point numbers (double).The following code illustrates all of the above:
While the simdjson library can be used in any project using C++ 11 and above, field iteration has special support C++ 17's destructuring syntax. For example:
The simdjson library also supports JSON pointer through the at_pointer() method, letting you reach further down into the document in a single call:
All simdjson APIs that can fail return simdjson_result<T>, which is a <value, error_code> pair. You can retrieve the value with .get(), like so:
The at() method has linear-time complexity: it should not be used to iterate over the content of an array.
This is how the example in "Using the Parsed JSON" could be written using only error code checking:
To ensure you don't write any code that uses exceptions, compile with SIMDJSON_EXCEPTIONS=OFF. For example, if including the project via cmake:
Users more comfortable with an exception flow may choose to directly cast the simdjson_result<T> to the desired type:
Sometimes you don't necessarily have a document with a known type, and are trying to generically inspect or walk over JSON elements. To do that, you can use iterators and the type() method. For example, here's a quick and dirty recursive function that verbosely prints the JSON document as JSON (* ignoring nuances like trailing commas and escaping strings, for brevity's sake):
If you're using simdjson to parse multiple documents, or in a loop, you should make a parser once and reuse it. The simdjson library will allocate and retain internal buffers between parses, keeping buffers hot in cache and keeping memory allocation and initialization to a minimum. In this manner, you can parse terabytes of JSON data without doing any new allocation.
You are only borrowing the document from the simdjson parser. Don't keep it long term!
This is key: don't keep the document&, dom::element, dom::array, dom::object or string_view objects you get back from the API. Convert them to C++ native values, structs and arrays that you own.
The simdjson library automatically expands its memory capacity when larger documents are parsed, so that you don't unexpectedly fail. In a short process that reads a bunch of files and then exits, this works pretty flawlessly.
Server loops, though, are long-running processes that will keep the parser around forever. This means that if you encounter a really, really large document, simdjson will not resize back down. The simdjson library lets you adjust your allocation strategy to prevent your server from growing without bound:
@@ -563,16 +563,16 @@ Server Loops: Long-Running Processes and Memory CapacityThe simdjson API provides access to the JSON DOM (document-object-model) content as a tree of dom::element instances, each representing an object, an array or an atomic type (null, true, false, number). These dom::element instances are lightweight objects (e.g., spanning 16 bytes) and it might be advantageous to pass them by value, as opposed to passing them by reference or by pointer.
The simdjson function parser.parse reads data from a padded buffer, containing SIMDJSON_PADDING extra bytes added at the end. If you are passing a padded_string to parser.parse or loading the JSON directly from disk (parser.load), padding is automatically handled. When calling parser.parse on a pointer (e.g., parser.parse(my_char_pointer, my_length_in_bytes)) a temporary copy is made by default with adequate padding and you, again, do not need to be concerned with padding.
Some users may not be able use our padded_string class or to load the data directly from disk (parser.load). They may need to pass data pointers to the library. If these users wish to avoid temporary copies and corresponding temporary memory allocations, they may want to call parser.parse with the realloc_if_needed parameter set to false (e.g., parser.parse(my_char_pointer, my_length_in_bytes, false)). In such cases, they need to ensure that there are at least SIMDJSON_PADDING extra bytes at the end that can be safely accessed and read. They do not need to initialize the padded bytes to any value in particular. The following example is safe:
```C++ const char *json = R"({"key":"value"})"; const size_t json_len = std::strlen(json); std::unique_ptr<char[]> padded_json_copy{new char[json_len + SIMDJSON_PADDING]}; memcpy(padded_json_copy.get(), json, json_len); memset(padded_json_copy.get() + json_len, 0, SIMDJSON_PADDING); simdjson::dom::parser parser; simdjson::dom::element element = parser.parse(padded_json_copy.get(), json_len, false); ````
Setting the realloc_if_needed parameter false in this manner may lead to better performance since copies are avoided, but it requires that the user takes more responsibilities: the simdjson library cannot verify that the input buffer was padded with SIMDJSON_PADDING extra bytes.
NDEBUG pre-processor directive when compiling the simdjson library. Importantly, using the optimization flags -O2 or -O3 under GCC and LLVM clang does not set the NDEBUG directrive, you must set it manually (e.g., -DNDEBUG).The simdjson library takes advantage of SIMD instruction sets such as NEON, SSE and AVX to achieve much of its speed. Because these instruction sets work differently, simdjson has to compile a different version of the JSON parser for different CPU architectures, often with different algorithms to take better advantage of a given CPU!
The current implementations are:
In many cases, you don't know where your compiled binary is going to run, so simdjson automatically compiles all the implementations into the executable. On Intel, it will include 4 implementations (icelake, haswell, westmere and fallback), on 64-bit ARM it will include just one since running dispatching is unnecessary, and on PPC it will include 2 (ppc64 and fallback).
If you know more about where you're going to run and want to save the space, you can disable any of these implementations at compile time with -DSIMDJSON_IMPLEMENTATION_X=0 (where X is ICELAKE, HASWELL, WESTMERE, ARM64, PPC64 and FALLBACK).
The simdjson library automatically sets header flags for each implementation as it compiles; there is no need to set architecture-specific flags yourself (e.g., -mavx2, /AVX2 or -march=haswell), and it may even break runtime dispatch and your binaries will fail to run on older processors. Note: for POWER9 processors make sure you compile it with -mcpu=power9 and -mtune=power9 to get maximum performance.
When you first use simdjson, it will detect the CPU you're running on, and swap over to the fastest implementation for it. This is a small, one-time cost and for many people will be paid the first time they call parse() or load().
You can check what implementation is running with active_implementation:
Implementation detection will happen in this case when you first call name().
You can list all available implementations, regardless of which one was selected:
When an implementation is not available, the bracket call simdjson::get_available_implementations()[name] will return the null pointer.
The available implementations have been compiled but may not necessarily be run safely on your system see Checking that an Implementation can Run on your System.
-If you're trying to do performance tests or see how different implementations of simdjson run, you can select the CPU architecture yourself:
You should call supported_by_runtime_system() to compare the processor's features with the need of the implementation.
... you want to read the entries (individual JSON documents) as quickly and as conveniently as possible. Importantly, the input might span several gigabytes, but you want to use a small (fixed) amount of memory. Ideally, you'd also like the parallelize the processing (using more than one core) to speed up the process.
-The main motivation for this piece of software is to achieve maximum speed and offer a better quality of life in parsing files containing multiple small JSON documents.
The JavaScript Object Notation (JSON) RFC7159 is a handy serialization format. However, when serializing a large sequence of values as an array, or a possibly indeterminate-length or never- ending sequence of values, JSON may be inconvenient.
Consider a sequence of one million values, each possibly one kilobyte when encoded – roughly one gigabyte. It is often desirable to process such a dataset incrementally without having to first read all of it before beginning to produce results.
-Before parsing anything, simdjson first preprocesses the JSON text by identifying all structural indexes (i.e. the starting position of any JSON value, as well as any important operators like ,, :, ] or }) and validating UTF8. This stage is referred to stage 1. However, during this process, simdjson has no knowledge of whether parsed a valid document, multiple documents, or even if the document is complete. Then, to iterate through the JSON text during parsing, we use what we call a JSON iterator that will navigate through the text using these structural indexes. This JSON iterator is not visible though, but it is the key component to make parsing work.
Prior to iterate_many, most people who had to parse a multiline JSON file would proceed by reading the file line by line, using a utility function like std::getline or equivalent, and would then use the parse on each of those lines. From a performance point of view, this process is highly inefficient, in that it requires a lot of unnecessary memory allocation and makes use of the getline function, which is fundamentally slow, slower than the act of parsing with simdjson (more on this here).
Unlike the popular parser RapidJson, our DOM does not require the buffer once the parsing job is completed, the DOM and the buffer are completely independent. The drawback of this architecture is that we need to allocate some additional memory to store our ParsedJson data, for every document inside a given file. Memory allocation can be slow and become a bottleneck, therefore, we want to minimize it as much as possible.
-To achieve a minimum amount of allocations, we opted for a design where we create only one parser object and therefore allocate its memory once, and then recycle it for every document in a given file. But, knowing that they often have largely varying size, we need to make sure that we allocate enough memory so that all the documents can fit. This value is what we call the batch size. As of right now, we need to manually specify a value for this batch size, it has to be at least as big as the biggest document in your file, but not too big so that it submerges the cached memory. The bigger the batch size, the fewer we need to make allocations. We found that 1MB is somewhat a sweet spot.
++ to read the next document, the JSON iterator moves to the start the next document.But how can we make use of threads if they are available? We found a pretty cool algorithm that allows us to quickly identify the position of the last JSON document in a given batch. Knowing exactly where the end of the last document in the batch is, we can safely parse through the last document without any worries that it might be incomplete. Therefore, we can run stage 1 on the next batch concurrently while parsing the documents in the current batch. Running stage 1 in a different thread can, in best cases, remove almost entirely its cost and replaces it by the overhead of a thread, which is orders of magnitude cheaper. Ain't that awesome!
Thread support is only active if thread supported is detected in which case the macro SIMDJSON_THREADS_ENABLED is set. Otherwise the library runs in single-thread mode.
A document_stream instance uses at most two threads: there is a main thread and a worker thread.
Since we want to offer flexibility and not restrict ourselves to a specific file format, we support any file that contains any amount of valid JSON document, separated by one or more character that is considered whitespace by the JSON spec. Anything that is not whitespace will be parsed as a JSON document and could lead to failure.
Whitespace Characters:
Example:
See basics.md for an overview of the API.
-From jsonlines.org:
Some users would like to know where the document they parsed is in the input array of bytes. It is possible to do so by accessing directly the iterator and calling its current_index() method which reports the location (in bytes) of the current document in the input stream. You may also call the source() method to get a std::string_view instance on the document and error() to check if there were any error.
Let us illustrate the idea with code:
@@ -206,7 +206,7 @@ Tracking your positionSome users may need to work with truncated streams. The simdjson may truncate documents at the very end of the stream that cannot possibly be valid JSON (e.g., they contain unclosed strings, unmatched brackets, unmatched braces). After iterating through the stream, you may query the truncated_bytes() method which tells you how many bytes were truncated. If the stream is made of full (whole) documents, then you should expect truncated_bytes() to return zero.
Consider the following example where a truncated document ({"key":"intentionally unclosed string) containing 39 bytes has been left within the stream. In such cases, the first two whole documents are parsed and returned, and the truncated_bytes() method returns 39.
Importantly, you should only call truncated_bytes() after iterating through all of the documents since the stream cannot tell whether there are truncated documents at the very end when it may not have accessed that part of the data yet.
We also support comma-separated documents, but with some performance limitations. The iterate_many function takes in an option to allow parsing of comma separated documents (which defaults on false). In this mode, the entire buffer is processed in one batch. Therefore, the total size of the document should not exceed the maximal capacity of the parser (4 GB). This mode also effectively disallow multithreading. It is therefore mostly suitable for not "very large" inputs. In this mode, the batch_size parameter is effectively ignored, as it is set to at least the document size.
Example:
diff --git a/md_doc_ondemand_design.html b/md_doc_ondemand_design.html index 19d5d85b8..9276aaf7a 100644 --- a/md_doc_ondemand_design.html +++ b/md_doc_ondemand_design.html @@ -151,7 +151,7 @@ $(document).ready(function(){initNavTree('md_doc_ondemand_design.html',''); initTo understand why On Demand is different, it is helpful to review the major approaches to parsing and parser APIs in use today.
-Many of the most usable, popular JSON APIs (including simdjson) deserialize into a DOM: an intermediate tree of objects, arrays and values. In this model, we convert the input data all at once into a tree-like structure (the DOM). The DOM is then accessed by the programmer like any other in-memory data structure. The resulting API let you refer to each array or object separately, using familiar techniques like iteration (for (auto value : array)) or indexing (object["key"]). In some cases, the values are even deserialized directly into familiar C++ constructs like vectors and maps.
The DOM approach is conceptually simple and "programmer friendly". Using the DOM tree is often easy enough that many users use the DOM as-is instead of creating their own custom data structures.
@@ -176,7 +176,7 @@ DOM ParsersWhat the simdjson library demonstrates is that a DOM API may be quite fast indeed: we can parse files at speeds of several gigabytes per second. However, in some instances, it may be possible to achieve even higher speeds.
-The event-based model (originally from the "Streaming API for XML") uses streaming to eliminate the cost of parsing and storing the entire JSON. In the event-based model, a core JSON engine parses the JSON document piece by piece, but instead of stuffing values in a DOM tree, it passes each value to a callback function, letting the user decide for themselves how to handle it. In such a model, the programmer may need to provide functions for all possible events (a number, a string, a new object, a new array, the array ends, the object ends, and so on). This allows programmers to work with much larger files without running out of memory.
The drawback is complexity: event-based APIs generally have you define a single callback for each type (e.g. string_field(std::string_view key, std::string_view value)). Because of this, the programmer suffers from context blindness: when they find a string they have to check where it is before they know what to do with it. Is this string the text of the tweet, the screen name, or something else? Are we even in a tweet right now, or is this from some other place in the document entirely? Though an event-based approach may allow superior performance, it is demanding of the programmer who must efficiently keep track of its current state within the JSON input.
Though an event-based approach might have its niche uses, we believe that it is rarely ideally suited. We suspect that it is mostly used when performance and memory is a concern, and no other option (except DOM) is readily available.
-In a schema-based model, the programmer provides a description of a data structure, and the parser constructs the data structure in question during parsing. These parsers take a schema–a description of your JSON, with field names, types, everything–and generate classes/structs in your language of choice, as well as a parser to deserialize the JSON into those structs. Some such parsers let you define your own data structures (struct) and they let a preprocessor inspects it and generates a custom JSON parser for it. Though not all of these schema-based parser generators generate a parser or even optimize for streaming, but they are able to in principle. Unlike the DOM and the event-based models, a schema-based approach assumes that the structure of the document is known at compile-time.
Pros of the schema-based approach:
The DOM and event-based parsing model suffer from type blindness: even when the programmer knows exactly what fields and what types are in the JSON document, the parser does not. This means it has to look at each value blind with a big "switch" statement, asking "is this a number? A string? A boolean? An array? An object?"
In modern processors, this kind of switch statement can make your program run slower than it needs to because of the high cost of branch misprediction. Indeed, modern processor cores rely on speculative execution for speed. They "read ahead" in your program, predicting which instructions to run as soon as the data is available. A single-threaded program can execute 2, 3 or even more instructions per cycle–largely because of speculative execution.
Unfortunately, when the processor mispredicts the instructions, typically due to a mispredicted branch, all of the work done from the misprediction has be discarded and started anew. The processor may have been executing 3 or 4 instructions per cycle, and consuming the corresponding power, but all of the work may have been wasteful.
Type blindness means that the processor has to guess, for every JSON value, whether it will be an array, an object, number, string or boolean since these correspond to distinct code paths. Though some JSON files have predictable content, we find in practice that many JSON files stress the branch prediction. Though branch predictors improve with each new generation of processors, the cost of branch mispredictions also tends to increase as pipelines expand, and the processors become able to schedule longer streams of instructions.
On Demand parsing is tailor-made to solve this problem at the source, parsing values only after the user declares their type by asking for a double, an int, a string, etc. It attempts to do so while preserving most of the flexibility of DOM parsing.
To help visualize the algorithm, we'll walk through the example C++ given at the top, for this JSON:
First, we declare a parser object that keeps internal buffers necessary for parsing. This can be reused to parse multiple JSON files, so you do not pay the high cost of allocating memory every time (and so it can stay in cache!).
@@ -465,9 +465,9 @@ Starting the iterationThis means you can very efficiently do things like read a single value from a JSON file, or take the top N, for example. It also means the things you don't use won't be fully validated. This is a general principle of On Demand: don't validate what you don't use. We still fully validate values you do use, however, as well as the objects and arrays that lead to them, so that you can be sure you get the information you need.
-When the user requests strings, we unescape them to a single string buffer much like the DOM parser so that users enjoy the same string performance as the core simdjson. We do not write the length to the string buffer, however; that is stored in the string_view instance we return to the user.
The On Demand API is powerful. To compensate, we add some safeguards to ensure that it can be used without fear in production systems:
We expect that the On Demand approach has many of the performance benefits of the schema-based approach, while providing a flexibility that is similar to that of the DOM-based approach.
The On Demand approach has some limitations:
parse_many).At this time we recommend the On Demand API in the following cases:
The On Demand API uses advanced architecture-specific code for many common processors to make JSON preprocessing and string parsing faster. By default, however, most c++ compilers will compile to the least common denominator (since the program could theoretically be run anywhere). Since On Demand is inlined into your own code, it cannot always use these advanced versions unless the compiler is told to target them.
On relevant systems, the On Demand API provides some support for runtime dispatching: that is, it will attempt to detect, at runtime, the instructions that your processor supports and optimize the code accordingly. However, it cannot always make full use of the features of your processor.
diff --git a/md_doc_parse_many.html b/md_doc_parse_many.html index 63d4ac130..32032de8f 100644 --- a/md_doc_parse_many.html +++ b/md_doc_parse_many.html @@ -96,7 +96,7 @@ $(document).ready(function(){initNavTree('md_doc_parse_many.html',''); initResiz... you want to read the entries (individual JSON documents) as quickly and as conveniently as possible. Importantly, the input might span several gigabytes, but you want to use a small (fixed) amount of memory. Ideally, you'd also like the parallelize the processing (using more than one core) to speed up the process.
-The main motivation for this piece of software is to achieve maximum speed and offer a better quality of life in parsing files containing multiple small JSON documents.
The JavaScript Object Notation (JSON) RFC7159 is a handy serialization format. However, when serializing a large sequence of values as an array, or a possibly indeterminate-length or never- ending sequence of values, JSON may be inconvenient.
Consider a sequence of one million values, each possibly one kilobyte when encoded – roughly one gigabyte. It is often desirable to process such a dataset incrementally without having to first read all of it before beginning to produce results.
-The following is a chart comparing the speed of the different alternatives to parse a multiline JSON. The simdjson library provides a threaded and non-threaded parse_many() implementation. As the figure below shows, if you can, use threads, but if you cannot, the unthreaded mode is still fast! 
The parsing in simdjson is divided into 2 stages. First, in stage 1, we parse the document and find all the structural indexes ({, }, ], [, ,, ", ...) and validate UTF8. Then, in stage 2, we go through the document again and build the tape using structural indexes found during stage 1. Although stage 1 finds the structural indexes, it has no knowledge of the structure of the document nor does it know whether it parsed a valid document, multiple documents, or even if the document is complete.
Prior to parse_many, most people who had to parse a multiline JSON file would proceed by reading the file line by line, using a utility function like std::getline or equivalent, and would then use the parse on each of those lines. From a performance point of view, this process is highly inefficient, in that it requires a lot of unnecessary memory allocation and makes use of the getline function, which is fundamentally slow, slower than the act of parsing with simdjson (more on this here).
Unlike the popular parser RapidJson, our DOM does not require the buffer once the parsing job is completed, the DOM and the buffer are completely independent. The drawback of this architecture is that we need to allocate some additional memory to store our ParsedJson data, for every document inside a given file. Memory allocation can be slow and become a bottleneck, therefore, we want to minimize it as much as possible.
-To achieve a minimum amount of allocations, we opted for a design where we create only one parser object and therefore allocate its memory once, and then recycle it for every document in a given file. But, knowing that they often have largely varying size, we need to make sure that we allocate enough memory so that all the documents can fit. This value is what we call the batch size. As of right now, we need to manually specify a value for this batch size, it has to be at least as big as the biggest document in your file, but not too big so that it submerges the cached memory. The bigger the batch size, the fewer we need to make allocations. We found that 1MB is somewhat a sweet spot.
++ to read the next document, we call stage 2 to parse the next document where we left off.But how can we make use of threads if they are available? We found a pretty cool algorithm that allows us to quickly identify the position of the last JSON document in a given batch. Knowing exactly where the end of the batch is, we no longer need for stage 2 to finish in order to load a new batch. We already know where to start the next batch. Therefore, we can run stage 1 on the next batch concurrently while the main thread is going through stage 2. Running stage 1 in a different thread can, in best cases, remove almost entirely its cost and replaces it by the overhead of a thread, which is orders of magnitude cheaper. Ain't that awesome!
Thread support is only active if thread supported is detected in which case the macro SIMDJSON_THREADS_ENABLED is set. Otherwise the library runs in single-thread mode.
A document_stream instance uses at most two threads: there is a main thread and a worker thread. You should expect the main thread to be fully occupied while the worker thread is partially busy (e.g., 80% of the time).
Since we want to offer flexibility and not restrict ourselves to a specific file format, we support any file that contains any amount of valid JSON document, separated by one or more character that is considered whitespace by the JSON spec. Anything that is not whitespace will be parsed as a JSON document and could lead to failure.
Whitespace Characters:
See basics.md for an overview of the API.
-From jsonlines.org:
Some users would like to know where the document they parsed is in the input array of bytes. It is possible to do so by accessing directly the iterator and calling its current_index() method which reports the location (in bytes) of the current document in the input stream. You may also call the source() method to get a std::string_view instance on the document.
Let us illustrate the idea with code:
@@ -196,7 +196,7 @@ Tracking your positionSome users may need to work with truncated streams. The simdjson may truncate documents at the very end of the stream that cannot possibly be valid JSON (e.g., they contain unclosed strings, unmatched brackets, unmatched braces). After iterating through the stream, you may query the truncated_bytes() method which tells you how many bytes were truncated. If the stream is made of full (whole) documents, then you should expect truncated_bytes() to return zero.
Consider the following example where a truncated document ({"key":"intentionally unclosed string) containing 39 bytes has been left within the stream. In such cases, the first two whole documents are parsed and returned, and the truncated_bytes() method returns 39.
In C/C++, the NDEBUG pre-processor directive is not set by default. When it is not set, the simdjson library does many additional checks that may impact negatively the performance. We recommend that, once your code is well tested, you define NDEBUG directive in your Release builds. The NDEBUG directive should be defined prior to including the simdjson.h header.
The NDEBUG directive is generally independent from optimization flags. For example, setting -O3 under GCC does not set the NDEBUG directive.
If you're using simdjson to parse multiple documents, or in a loop, you should make a parser once and reuse it. The simdjson library will allocate and retain internal buffers between parses, keeping buffers hot in cache and keeping memory allocation and initialization to a minimum. In this manner, you can parse terabytes of JSON data without doing any new allocation.
We recommend against creating many std::string or simdjson::padded_string instances to store the JSON content in your application. Creating many non-trivial objects is convenient but often surprisingly slow. Instead, as much as possible, you should allocate (once or a few times) reusable memory buffers where you write your JSON content. If you have a buffer json_str (of type char*) allocated for capacity bytes and you store a JSON document spanning length bytes, you can pass it to simdjson as follows:
or simply
The On Demand approach also automatically expands its memory capacity when larger documents are parsed. However, for longer processes where very large files are processed (such as server loops), this capacity is not resized down. On Demand also lets you adjust the maximal capacity that the parser can process:
set_max_capacity().
There is a memory allocation performance cost the first time you process a large file (e.g. 100MB). Between the cost of allocation, the fact that the memory is not in cache, and the initial zeroing of memory, on some systems, allocation runs far slower than parsing (e.g., 1.4GB/s). Reusing the parser mitigates this by paying the cost once, but does not eliminate it.
In large file use cases, enabling transparent huge page allocation on the OS can help a lot. We haven't found the right way to do this on Windows or OS/X, but on Linux, you can enable transparent huge page allocation with a command like:
@@ -173,7 +173,7 @@ Large files and huge page supportIn general, when running benchmarks over large files, we recommend that you report performance numbers with and without huge pages if possible. Furthermore, you should amortize the parsing (e.g., by parsing several large files) to distinguish the time spent parsing from the time spent allocating memory. If you are using the parse benchmarking tool provided with the simdjson library, you can use the -H flag to omit the memory allocation cost from the benchmark results.
Some JSON files contain many floating-point values. It is the case with many GeoJSON files. Accurately parsing decimal strings into binary floating-point values with proper rounding is challenging. To our knowledge, it is not possible, in general, to parse streams of numbers at gigabytes per second using a single core. While using the simdjson library, it is possible that you might be limited to a few hundred megabytes per second if your JSON documents are densely packed with floating-point values.
On Intel and AMD Windows platforms, Microsoft Visual Studio enables programmers to build either 32-bit (x86) or 64-bit (x64 or ARM64) binaries. We urge you to always use 64-bit mode. Visual Studio 2019 should default on 64-bit builds when you have a 64-bit version of Windows, which we recommend.
When compiling with Visual Studio, we recommend the flags /Ob2 /O2 or better. We do not recommend that you compile simdjson with architecture-specific flags such as arch:AVX2. The simdjson library automatically selects the best execution kernel at runtime.
Recent versions of Microsoft Visual Studio on Windows provides support for the LLVM Clang compiler. You only need to install the "Clang compiler" optional component (ClangCL). You may also get a copy of the 64-bit LLVM CLang compiler for Windows directly from LLVM. The simdjson library fully supports the LLVM Clang compiler under Windows. In fact, you may get better performance out of simdjson with the LLVM Clang compiler than with the regular Visual Studio compiler. Meanwhile the LLVM CLang compiler is binary compatible with Visual Studio which means that you can combine their binaries (executables and libraries).
Under Windows, we also support the GNU GCC compiler via MSYS2. The performance of 64-bit MSYS2 under Windows excellent (on par with Linux).
-The simdjson library relies on SIMD instructions. SIMD instructions are the public transportation of computing. Instead of using 4 distinct instructions to add numbers, you can replace them with a single instruction that does the same work. Though the one instruction is slightly more expensive, the energy used per unit of work is much less with SIMD. If you can increase your speed using SIMD instructions (NEON, SSE, AVX), you should expect to reduce your power usage.
The SIMD instructions that simdjson relies upon (SSE and AVX under x64, NEON under ARM, ALTIVEC under PPC) are routinely part of runtime libraries (e.g., Go, Glibc, LLVM, Rust, Java, PHP). What distinguishes the simdjson library is that it is built from the ground up to benefit from these instructions.
diff --git a/md_doc_tape.html b/md_doc_tape.html index a5ae64750..e05155da0 100644 --- a/md_doc_tape.html +++ b/md_doc_tape.html @@ -93,7 +93,7 @@ $(document).ready(function(){initNavTree('md_doc_tape.html',''); initResizable()We parse a JSON document to a tape. A tape is an array of 64-bit values. Each node encountered in the JSON document is written to the tape using one or more 64-bit tape elements; the layout of the tape is in "document order": elements are stored as they are encountered in the JSON document.
Throughout, little endian encoding is assumed. The tape is indexed starting at 0 (the first element is at index 0).
-It is sometimes useful to start with an example. Consider the following JSON document:
The following is a dump of the content of the tape, with the first number of each line representing the index of a tape element.
-| 38 | r // pointing to 0 (start root) |
Most tape elements are written as ‘('c’ << 56) + xwhere'c'‘ is some ASCII character determining the type of the element (out of 't’, 'f', 'n', 'l', 'u', 'd', '"', '{', '}', '[', ']' ,'r') and where x is a 56-bit value called the payload. The payload is normally interpreted as an unsigned 56-bit integer. Note that 56-bit integers can be quite large.
Performance consideration: We believe that accessing the tape in regular units of 64 bits is more important for performance than saving memory.
-Simple JSON nodes are represented with one tape element:
true is represented as the 64-bit value('t' << 56).false is represented as the 64-bit value('f' << 56)`.Integer values are represented as two 64-bit tape elements:
followed by the 64-bit integer value literally. Integer values are assumed to be signed 64-bit values, using two's complement notation.Performance consideration: We store numbers of the main tape because we believe that locality of reference is helpful for performance.
-Each JSON document will have two special 64-bit tape elements representing a root node, one at the beginning and one at the end.
All of the parsed document is located between these two 64-bit tape elements.
Hint: We can read the first tape element to determine the length of the tape.
-We prefix the string data itself by a 32-bit header to be interpreted as a 32-bit integer. It indicates the length of the string. The actual string data starts at an offset of 4 bytes.
We store string values using UTF-8 encoding with null termination on a separate tape. A string value is represented on the main tape as the 64-bit tape element ‘(’"' << 56) + xwhere the payloadx` is the location on the string tape of the null-terminated string.
JSON arrays are represented using two 64-bit tape elements.
All the content of the array is located between these two tape elements, including arrays and objects.
Performance consideration: We can skip the content of an array entirely by accessing the first 64-bit tape element, reading the payload and moving to the corresponding index on the tape.
-JSON objects are represented using two 64-bit tape elements.
Functions | |
| +std::string | json_path_to_pointer_conversion (std::string_view json_path) |
| std::ostream & | operator<< (std::ostream &out, json_type type) noexcept |
| Write the JSON type to the output stream. More... | |
| simdjson_inline simdjson_result< SIMDJSON_IMPLEMENTATION::ondemand::value > | at_pointer (std::string_view json_pointer) noexcept |
| +simdjson_inline simdjson_result< SIMDJSON_IMPLEMENTATION::ondemand::value > | at_path (std::string_view json_path) noexcept |
| simdjson_inline simdjson_result< std::string_view > | raw_json () noexcept |
Definition at line 712 of file document.h.
+Definition at line 728 of file document.h.
std::string_view document::raw_json_token() const noexcept
std::string_view document::raw_json_token() const noexcept
-Definition at line 563 of file document-inl.h.
+Definition at line 582 of file document-inl.h.
diff --git a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.js b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.js index 4d9d82f05..8f791a3eb 100644 --- a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.js +++ b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.js @@ -3,6 +3,7 @@ var structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_ [ "simdjson_result", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#aee14d172c38cccaebd412e89b9ddb6fd", null ], [ "at", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#a78feffa1a15a0ae2f244e87d89bbe372", null ], [ "at_end", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#ab4ad542b6ecca93a5886f3c1134a8831", null ], + [ "at_path", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#a6eaf8b3346df0929f74a7a3581f94f3b", null ], [ "at_pointer", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#a17135304a51a3cf08cc802630f5cc1d0", null ], [ "begin", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#a9a751f7a061bc6e8d3159556466edbf0", null ], [ "count_elements", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document_01_4.html#ac4c6cfbf267a75a8448b7353cb1f53f5", null ], diff --git a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html index 24702c4a1..223f1d72f 100644 --- a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html +++ b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html @@ -252,6 +252,9 @@ simdjson_inline sim
Public Member Functions inherited from simdjson::SIMDJSON_IMPLEMENTATION::implementation_simdjson_result_base< SIMDJSON_IMPLEMENTATION::ondemand::document_reference >Definition at line 788 of file document.h.
+Definition at line 805 of file document.h.
std::string_view document_reference::raw_json_token() const noexcept
std::string_view document_reference::raw_json_token() const noexcept
-Definition at line 848 of file document-inl.h.
+Definition at line 872 of file document-inl.h.
diff --git a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.js b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.js index 10876e669..60ccc5e86 100644 --- a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.js +++ b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.js @@ -3,6 +3,7 @@ var structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_ [ "simdjson_result", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#aa53af9357f3c3aa144ccda80ed709d4c", null ], [ "simdjson_result", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#a68051e56ba7cbc7951bdc49d02bb62fa", null ], [ "at", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#ae1557f700923c9f18b75f2d320e434c7", null ], + [ "at_path", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#afcaa2ac76fe35a23a80f71a4be86807f", null ], [ "at_pointer", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#a02a7afea763acd3b79a77198c26aa947", null ], [ "begin", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#a32724251c423c33cd1fb095d6f8faa40", null ], [ "count_elements", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1document__reference_01_4.html#a84d35046d2328c1b52052b60abdfff5f", null ], diff --git a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object_01_4-members.html b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object_01_4-members.html index 801b98d26..49fab0f2a 100644 --- a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object_01_4-members.html +++ b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1object_01_4-members.html @@ -94,36 +94,37 @@ $(document).ready(function(){initNavTree('structsimdjson_1_1simdjson__result_3_0This is the complete list of members for simdjson::simdjson_result< SIMDJSON_IMPLEMENTATION::ondemand::object >, including all inherited members.
This is the complete list of members for simdjson::simdjson_result< SIMDJSON_IMPLEMENTATION::ondemand::value >, including all inherited members.
int32_t current_depth() const noexcept
int32_t current_depth() const noexcept
-Definition at line 470 of file value-inl.h.
+Definition at line 485 of file value-inl.h.
@@ -380,7 +383,7 @@ Additional Inherited Memberssimdjson_result<const char *> current_location() noexcept
simdjson_result<const char *> current_location() noexcept
-Definition at line 465 of file value-inl.h.
+Definition at line 480 of file value-inl.h.
@@ -426,7 +429,7 @@ Additional Inherited MembersThis is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
-Definition at line 287 of file value-inl.h.
+Definition at line 302 of file value-inl.h.
@@ -467,7 +470,7 @@ Additional Inherited MembersThis is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
-Definition at line 296 of file value-inl.h.
+Definition at line 311 of file value-inl.h.
@@ -497,7 +500,7 @@ Additional Inherited Membersstd::string_view value::raw_json_token() const noexcept
std::string_view value::raw_json_token() const noexcept
-Definition at line 455 of file value-inl.h.
+Definition at line 470 of file value-inl.h.
@@ -527,7 +530,7 @@ Additional Inherited MembersGet the type of this JSON value.
NOTE: If you're only expecting a value to be one type (a typical case), it's generally better to just call .get_double, .get_string, etc. and check for INCORRECT_TYPE (or just let it throw an exception).
-Definition at line 391 of file value-inl.h.
+Definition at line 406 of file value-inl.h.
diff --git a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.js b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.js index 7756d638a..e80aabca6 100644 --- a/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.js +++ b/structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.js @@ -2,6 +2,7 @@ var structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_ [ [ "simdjson_result", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.html#a862809692781f445bd41c93c9ba884aa", null ], [ "at", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.html#a2133bb3e3ca52ee35803cdcbae374d88", null ], + [ "at_path", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.html#a2ae036a9420536eed838f29c290d4a66", null ], [ "at_pointer", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.html#a6d591c53c2d0e8a4ad71e171dafa45f8", null ], [ "begin", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.html#a4fcb1a87bdcdd717b09af375280dcd34", null ], [ "count_elements", "structsimdjson_1_1simdjson__result_3_01_s_i_m_d_j_s_o_n___i_m_p_l_e_m_e_n_t_a_t_i_o_n_1_1ondemand_1_1value_01_4.html#a04ed905c5d3108cdbb3e9801d1e30486", null ], diff --git a/value-inl_8h_source.html b/value-inl_8h_source.html index 13d345c29..babc0b240 100644 --- a/value-inl_8h_source.html +++ b/value-inl_8h_source.html @@ -99,522 +99,549 @@ $(document).ready(function(){initNavTree('value-inl_8h_source.html',''); initRes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -