Public Types
using	value_t = detail::value_t
using	json_pointer = ::nlohmann::json_pointer<basic_json>
template<typename T, typename SFINAE>
using	json_serializer = JSONSerializer<T, SFINAE>
using	error_handler_t = detail::error_handler_t
using	initializer_list_t = std::initializer_list<detail::json_ref<basic_json>>
using	input_format_t = detail::input_format_t
using	json_sax_t = json_sax<basic_json>
using	parse_error
using	invalid_iterator = detail::invalid_iterator
using	type_error = detail::type_error
using	out_of_range = detail::out_of_range
using	other_error = detail::other_error
using	reference
using	const_reference = const value_type&
using	difference_type = std::ptrdiff_t
using	size_type = std::size_t
using	allocator_type = AllocatorType<basic_json>
using	pointer = typename std::allocator_traits<allocator_type>::pointer
using	const_pointer = typename std::allocator_traits<allocator_type>::const_pointer
using	iterator = iter_impl<basic_json>
using	const_iterator = iter_impl<const basic_json>
using	reverse_iterator = json_reverse_iterator<typename basic_json::iterator>
using	const_reverse_iterator = json_reverse_iterator<typename basic_json::const_iterator>
using	object_t
	a type for an object
using	array_t = ArrayType<basic_json, AllocatorType<basic_json>>
	a type for an array
using	string_t = StringType
	a type for a string
using	boolean_t = BooleanType
	a type for a boolean
using	number_integer_t = NumberIntegerType
	a type for a number (integer)
using	number_unsigned_t = NumberUnsignedType
	a type for a number (unsigned)
using	number_float_t = NumberFloatType
	a type for a number (floating-point)
using	parse_event_t = typename parser::parse_event_t
	parser event types
using	parser_callback_t = typename parser::parser_callback_t
	per-element parser callback type

Static Public Member Functions
*static allocator_type	get_allocator ()
	returns the allocator associated with the container
static JSON_HEDLEY_WARN_UNUSED_RESULT basic_json	meta ()
	returns version information on the library

Public Attributes
*JSON	Pointer
*SAX interface	type
**name constructors and destructors Constructors of class ref basic_json copy move constructor copy *	assignment
**name constructors and destructors Constructors of class ref basic_json copy move constructor copy static functions creating and the destructor **the value of the current element json_value	m_value = {}

Static Public Attributes
**name constructors and destructors Constructors of class ref basic_json copy move constructor copy static functions creating	objects

Friends
template<detail::value_t>
struct	detail::external_constructor
template<typename BasicJsonType>
class	::nlohmann::detail::iter_impl
template<typename BasicJsonType, typename CharType>
class	::nlohmann::detail::binary_writer
template<typename BasicJsonType, typename SAX>
class	::nlohmann::detail::binary_reader
template<typename BasicJsonType>
class	::nlohmann::detail::json_sax_dom_parser
template<typename BasicJsonType>
class	::nlohmann::detail::json_sax_dom_callback_parser

Member Typedef Documentation

◆ array_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::array_t = ArrayType<basic_json, AllocatorType<basic_json>>

a type for an array

RFC 7159 describes JSON arrays as follows:

An array is an ordered sequence of zero or more values.

To store objects in C++, a type is defined by the template parameters explained below.

Template Parameters

ArrayType	container type to store arrays (e.g., std::vector or std::list)
AllocatorType	allocator to use for arrays (e.g., std::allocator)

Default type

With the default values for ArrayType (std::vector) and AllocatorType (std::allocator), the default value for array_t is:

std::vector<
  basic_json, // value_type
  std::allocator<basic_json> // allocator_type
>

Limits

RFC 7159 specifies:

An implementation may set limits on the maximum depth of nesting.

In this class, the array's limit of nesting is not explicitly constrained. However, a maximum depth of nesting may be introduced by the compiler or runtime environment. A theoretical limit can be queried by calling the max_size function of a JSON array.

Storage

Arrays are stored as pointers in a basic_json type. That is, for any access to array values, a pointer of type array_t* must be dereferenced.

See also: object_t – type for an object value

Since: version 1.0.0

◆ boolean_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::boolean_t = BooleanType

a type for a boolean

RFC 7159 implicitly describes a boolean as a type which differentiates the two literals true and false.

To store objects in C++, a type is defined by the template parameter BooleanType which chooses the type to use.

Default type

With the default values for BooleanType (bool), the default value for boolean_t is:

bool

Storage

Boolean values are stored directly inside a basic_json type.

Since: version 1.0.0

◆ number_float_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::number_float_t = NumberFloatType

a type for a number (floating-point)

RFC 7159 describes numbers as follows:

The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed. (...) Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.

This description includes both integer and floating-point numbers. However, C++ allows more precise storage if it is known whether the number is a signed integer, an unsigned integer or a floating-point number. Therefore, three different types, number_integer_t, number_unsigned_t and number_float_t are used.

To store floating-point numbers in C++, a type is defined by the template parameter NumberFloatType which chooses the type to use.

Default type

With the default values for NumberFloatType (double), the default value for number_float_t is:

double

Default behavior

The restrictions about leading zeros is not enforced in C++. Instead, leading zeros in floating-point literals will be ignored. Internally, the value will be stored as decimal number. For instance, the C++ floating-point literal 01.2 will be serialized to 1.2. During deserialization, leading zeros yield an error.
Not-a-number (NaN) values will be serialized to null.

Limits

RFC 7159 states:

This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.

This implementation does exactly follow this approach, as it uses double precision floating-point numbers. Note values smaller than -1.79769313486232e+308 and values greater than 1.79769313486232e+308 will be stored as NaN internally and be serialized to null.

Storage

Floating-point number values are stored directly inside a basic_json type.

See also: number_integer_t – type for number values (integer); number_unsigned_t – type for number values (unsigned integer)

Since: version 1.0.0

◆ number_integer_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::number_integer_t = NumberIntegerType

a type for a number (integer)

RFC 7159 describes numbers as follows:

The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed. (...) Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.

This description includes both integer and floating-point numbers. However, C++ allows more precise storage if it is known whether the number is a signed integer, an unsigned integer or a floating-point number. Therefore, three different types, number_integer_t, number_unsigned_t and number_float_t are used.

To store integer numbers in C++, a type is defined by the template parameter NumberIntegerType which chooses the type to use.

Default type

With the default values for NumberIntegerType (int64_t), the default value for number_integer_t is:

int64_t

Default behavior

The restrictions about leading zeros is not enforced in C++. Instead, leading zeros in integer literals lead to an interpretation as octal number. Internally, the value will be stored as decimal number. For instance, the C++ integer literal 010 will be serialized to 8. During deserialization, leading zeros yield an error.
Not-a-number (NaN) values will be serialized to null.

Limits

RFC 7159 specifies:

An implementation may set limits on the range and precision of numbers.

When the default type is used, the maximal integer number that can be stored is 9223372036854775807 (INT64_MAX) and the minimal integer number that can be stored is -9223372036854775808 (INT64_MIN). Integer numbers that are out of range will yield over/underflow when used in a constructor. During deserialization, too large or small integer numbers will be automatically be stored as number_unsigned_t or number_float_t.

RFC 7159 further states:

Note that when such software is used, numbers that are integers and are in the range \([-2^{53}+1, 2^{53}-1]\) are interoperable in the sense that implementations will agree exactly on their numeric values.

As this range is a subrange of the exactly supported range [INT64_MIN, INT64_MAX], this class's integer type is interoperable.

Storage

Integer number values are stored directly inside a basic_json type.

See also: number_float_t – type for number values (floating-point); number_unsigned_t – type for number values (unsigned integer)

Since: version 1.0.0

◆ number_unsigned_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::number_unsigned_t = NumberUnsignedType

a type for a number (unsigned)

RFC 7159 describes numbers as follows:

The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed. (...) Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.

This description includes both integer and floating-point numbers. However, C++ allows more precise storage if it is known whether the number is a signed integer, an unsigned integer or a floating-point number. Therefore, three different types, number_integer_t, number_unsigned_t and number_float_t are used.

To store unsigned integer numbers in C++, a type is defined by the template parameter NumberUnsignedType which chooses the type to use.

Default type

With the default values for NumberUnsignedType (uint64_t), the default value for number_unsigned_t is:

uint64_t

Default behavior

The restrictions about leading zeros is not enforced in C++. Instead, leading zeros in integer literals lead to an interpretation as octal number. Internally, the value will be stored as decimal number. For instance, the C++ integer literal 010 will be serialized to 8. During deserialization, leading zeros yield an error.
Not-a-number (NaN) values will be serialized to null.

Limits

RFC 7159 specifies:

An implementation may set limits on the range and precision of numbers.

When the default type is used, the maximal integer number that can be stored is 18446744073709551615 (UINT64_MAX) and the minimal integer number that can be stored is 0. Integer numbers that are out of range will yield over/underflow when used in a constructor. During deserialization, too large or small integer numbers will be automatically be stored as number_integer_t or number_float_t.

RFC 7159 further states:

Note that when such software is used, numbers that are integers and are in the range \([-2^{53}+1, 2^{53}-1]\) are interoperable in the sense that implementations will agree exactly on their numeric values.

As this range is a subrange (when considered in conjunction with the number_integer_t type) of the exactly supported range [0, UINT64_MAX], this class's integer type is interoperable.

Storage

Integer number values are stored directly inside a basic_json type.

See also: number_float_t – type for number values (floating-point); number_integer_t – type for number values (integer)

Since: version 2.0.0

◆ object_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::object_t

Initial value:

{
 
    using object_comparator_t = std::less<StringType> ObjectType<StringType,
          basic_json,
          object_comparator_t,
          AllocatorType<std::pair<const StringType,
          basic_json>>>

a type for an object

RFC 7159 describes JSON objects as follows:

An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.

To store objects in C++, a type is defined by the template parameters described below.

Template Parameters

ObjectType	the container to store objects (e.g., std::map or std::unordered_map)
StringType	the type of the keys or names (e.g., std::string). The comparison function std::less<StringType> is used to order elements inside the container.
AllocatorType	the allocator to use for objects (e.g., std::allocator)

Default type

With the default values for ObjectType (std::map), StringType (std::string), and AllocatorType (std::allocator), the default value for object_t is:

std::map<
  std::string, // key_type
  basic_json, // value_type
  std::less<std::string>, // key_compare
  std::allocator<std::pair<const std::string, basic_json>> // allocator_type
>

Behavior

The choice of object_t influences the behavior of the JSON class. With the default type, objects have the following behavior:

When all names are unique, objects will be interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings.
When the names within an object are not unique, it is unspecified which one of the values for a given key will be chosen. For instance, {"key": 2, "key": 1} could be equal to either {"key": 1} or {"key": 2}.
Internally, name/value pairs are stored in lexicographical order of the names. Objects will also be serialized (see dump) in this order. For instance, {"b": 1, "a": 2} and {"a": 2, "b": 1} will be stored and serialized as {"a": 2, "b": 1}.
When comparing objects, the order of the name/value pairs is irrelevant. This makes objects interoperable in the sense that they will not be affected by these differences. For instance, {"b": 1, "a": 2} and {"a": 2, "b": 1} will be treated as equal.

Limits

RFC 7159 specifies:

An implementation may set limits on the maximum depth of nesting.

In this class, the object's limit of nesting is not explicitly constrained. However, a maximum depth of nesting may be introduced by the compiler or runtime environment. A theoretical limit can be queried by calling the max_size function of a JSON object.

Storage

Objects are stored as pointers in a basic_json type. That is, for any access to object values, a pointer of type object_t* must be dereferenced.

See also: array_t – type for an array value

Since: version 1.0.0

Note: The order name/value pairs are added to the object is not preserved by the library. Therefore, iterating an object may return name/value pairs in a different order than they were originally stored. In fact, keys will be traversed in alphabetical order as std::map with std::less is used by default. Please note this behavior conforms to RFC 7159, because any order implements the specified "unordered" nature of JSON objects.

◆ parse_error

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::parse_error

Initial value:

{
 
     *  @copydoc detail::exception
    using exception = detail::exception detail::parse_error

◆ parse_event_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::parse_event_t = typename parser::parse_event_t

parser event types

The parser callback distinguishes the following events:

object_start: the parser read { and started to process a JSON object
key: the parser read a key of a value in an object
object_end: the parser read } and finished processing a JSON object
array_start: the parser read [ and started to process a JSON array
array_end: the parser read ] and finished processing a JSON array
value: the parser finished reading a JSON value

Example when certain parse events are triggered

See also: parser_callback_t for more information and examples

◆ parser_callback_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::parser_callback_t = typename parser::parser_callback_t

per-element parser callback type

With a parser callback function, the result of parsing a JSON text can be influenced. When passed to parse, it is called on certain events (passed as parse_event_t via parameter event) with a set recursion depth depth and context JSON value parsed. The return value of the callback function is a boolean indicating whether the element that emitted the callback shall be kept or not.

We distinguish six scenarios (determined by the event type) in which the callback function can be called. The following table describes the values of the parameters depth, event, and parsed.

parameter event	description	parameter depth	parameter parsed
parse_event_t::object_start	the parser read { and started to process a JSON object	depth of the parent of the JSON object	a JSON value with type discarded
parse_event_t::key	the parser read a key of a value in an object	depth of the currently parsed JSON object	a JSON string containing the key
parse_event_t::object_end	the parser read } and finished processing a JSON object	depth of the parent of the JSON object	the parsed JSON object
parse_event_t::array_start	the parser read [ and started to process a JSON array	depth of the parent of the JSON array	a JSON value with type discarded
parse_event_t::array_end	the parser read ] and finished processing a JSON array	depth of the parent of the JSON array	the parsed JSON array
parse_event_t::value	the parser finished reading a JSON value	depth of the value	the parsed JSON value

Example when certain parse events are triggered

Discarding a value (i.e., returning false) has different effects depending on the context in which function was called:

Discarded values in structured types are skipped. That is, the parser will behave as if the discarded value was never read.
In case a value outside a structured type is skipped, it is replaced with null. This case happens if the top-level element is skipped.

Parameters

[in]	depth	the depth of the recursion during parsing
[in]	event	an event of type parse_event_t indicating the context in the callback function has been called
[in,out]	parsed	the current intermediate parse result; note that writing to this value has no effect for parse_event_t::key events

Returns: Whether the JSON value which called the function during parsing should be kept (true) or not (false). In the latter case, it is either skipped completely or replaced by an empty discarded object.

See also: parse for examples

Since: version 1.0.0

◆ reference

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::reference

Initial value:

{
 
     *  the type of elements in a basic_json container
    using value_type = basic_json value_type&

◆ string_t

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

using nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::string_t = StringType

a type for a string

RFC 7159 describes JSON strings as follows:

A string is a sequence of zero or more Unicode characters.

To store objects in C++, a type is defined by the template parameter described below. Unicode values are split by the JSON class into byte-sized characters during deserialization.

Template Parameters

StringType the container to store strings (e.g., std::string). Note this container is used for keys/names in objects, see object_t.

Default type

With the default values for StringType (std::string), the default value for string_t is:

std::string

Encoding

Strings are stored in UTF-8 encoding. Therefore, functions like std::string::size() or std::string::length() return the number of bytes in the string rather than the number of characters or glyphs.

String comparison

RFC 7159 states:

Software implementations are typically required to test names of object members for equality. Implementations that transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit, are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings. For example, implementations that compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal.

This implementation is interoperable as it does compare strings code unit by code unit.

Storage

String values are stored as pointers in a basic_json type. That is, for any access to string values, a pointer of type string_t* must be dereferenced.

Since: version 1.0.0

Member Function Documentation

◆ meta()

template<template< typename U, typename V, typename... Args > class ObjectType = std::map, template< typename U, typename... Args > class ArrayType = std::vector, class StringType = std::string, class BooleanType = bool, class NumberIntegerType = std::int64_t, class NumberUnsignedType = std::uint64_t, class NumberFloatType = double, template< typename U > class AllocatorType = std::allocator, template< typename T, typename SFINAE=void > class JSONSerializer = adl_serializer>

JSON_HEDLEY_WARN_UNUSED_RESULT basic_json nlohmann::basic_json< ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer >::meta ( )

inlinestatic

returns version information on the library

This function returns a JSON object with information about the library, including the version number and information on the platform and compiler.

Returns

JSON object holding version information

key	description
compiler	Information on the used compiler. It is an object with the following keys: c++ (the used C++ standard), family (the compiler family; possible values are clang, icc, gcc, ilecpp, msvc, pgcpp, sunpro, and unknown), and version (the compiler version).
copyright	The copyright line for the library as string.
name	The name of the library as string.
platform	The used platform as string. Possible values are win32, linux, apple, unix, and unknown.
url	The URL of the project as string.
version	The version of the library. It is an object with the following keys: major, minor, and patch as defined by Semantic Versioning, and string (the version string).

@liveexample{The following code shows an example output of the meta() function.,meta}

@exceptionsafety Strong guarantee: if an exception is thrown, there are no changes to any JSON value.

@complexity Constant.

Since: 2.1.0

The documentation for this class was generated from the following file:

code/qcommon/json.hpp

Public Types

Static Public Member Functions

Public Attributes

Static Public Attributes

Friends

Member Typedef Documentation

◆ array_t

Default type

Limits

Storage

◆ boolean_t

Default type

Storage

◆ number_float_t

Default type

Default behavior

Limits

Storage

◆ number_integer_t

Default type

Default behavior

Limits

Storage

◆ number_unsigned_t

Default type

Default behavior

Limits

Storage

◆ object_t

Default type

Behavior

Limits

Storage

◆ parse_error

◆ parse_event_t

◆ parser_callback_t

◆ reference

◆ string_t

Default type

Encoding

String comparison

Storage

Member Function Documentation

◆ meta()