2. Boost Json Translation (zh_Hans)
3. English
4. Zen

3 :18
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Description 11/10000 · 11
3 :18
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The interface and functionality of <<ref_string>> is the same as {std_string} except that: 90/10000 · 90
3 :36
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In cases where you know that a <<ref_value>> contains a number but don't know its <<ref_kind>>, `value::to_number` can be used to convert the <<ref_value>> to an arithmetic type: 178/10000 · 178
3 :20
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If library-provided conversions are suitable for you, you have the option to use direct conversions. This also puts the requirement of being default constructible on many of your types. 185/10000 · 185
3 :25
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These `tag_invoke` overloads take an extra `as_string` parameter, which disambiguates this specific representation of `ip_address` from all other potential representations. In order to take advantage of them one needs to pass an `as_string` object to <<ref_value_from>> or <<ref_value_to>> as the last argument: 311/10000 · 311
3 :17
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Previously a number of conversion type traits, like <<ref_is_tuple_like>> or <<ref_is_sequence_like>>, were introduced. The library tries the traits one after another and uses the implementation that corresponds to the first matching trait. In some cases, though, a type would match a trait with a higher priority, but the user intends for it to belong to a lower priority category. If this happens the user can specialize the trait that's not supposed to match for that type to be an equivalent of `std::false_type`. 518/10000 · 518
3 :21
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The library provides non-throwing conversions for all the categories of types it supports with <<ref_value_to>>. If a user wants to use it with custom types, an overload of `tag_invoke` of this form needs to be provided: 220/10000 · 220
3 :31
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For the type `T`, the appropriate conversion approach is chosen from the following list of categories. The first matching category is selected. 143/10000 · 143
3 :23
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — That being said, if your types are default-constructible and you don't need the customisability allowed by <<ref_value_to>> and <<ref_value_from>>, then you can get a significant performance boost with direct conversions. 221/10000 · 221
3 :24
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — After that the definitions of `tag_invoke` overloads should be provided. These overloads have to be templates, since <<ref_value>> is only forward-declared and hence is an incomplete type. 188/10000 · 188
3 :20
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As the conversion result is set via an output parameter of type `value&`, the intended <<ref_storage_ptr>> is correctly propagated. But users still should take care to not create temporaries using the default {ref_memory_resource} by accident. 243/10000 · 243
3 :18
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — type-erased {ref_memory_resource}. 34/10000 · 34
3 :31
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — While the system works, it has some usability problems: 55/10000 · 55
3 :19
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :leveloffset: +1 16/10000 · 16
3 :18
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a {ref_polymorphic_allocator}. 30/10000 · 30
3 :18
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Description 11/10000 · 11
3 :18
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Name 4/10000 · 4
3 :19
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — include::parsing.adoc[] include::serializing.adoc[] 51/10000 · 51
4 :4
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — https://github.com/boostorg/json/tree/develop[`develop`] 56/10000 · 56
4 :36
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a| *Functions* + <<ref_get>> + <<ref_get_null_resource>> + <<ref_make_shared_resource>> + <<ref_parse>> + <<ref_parse_into>> + <<ref_result_from_errno>> + <<ref_serialize>> + <<ref_to_string>> + <<ref_try_value_to>> + <<ref_value_from>> + <<ref_value_to>> + <<ref_visit>> 271/10000 · 271