1# basic_json::object_t 2 3```cpp 4using object_t = ObjectType<StringType, 5 basic_json, 6 object_comparator_t, 7 AllocatorType<std::pair<const StringType, basic_json>>>; 8``` 9 10The type used to store JSON objects. 11 12[RFC 8259](https://tools.ietf.org/html/rfc8259) describes JSON objects as follows: 13> An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a 14> string, number, boolean, null, object, or array. 15 16To store objects in C++, a type is defined by the template parameters described below. 17 18## Template parameters 19 20`ObjectType` 21: the container to store objects (e.g., `std::map` or `std::unordered_map`) 22 23`StringType` 24: the type of the keys or names (e.g., `std::string`). The comparison function `std::less<StringType>` is used to 25 order elements inside the container. 26 27`AllocatorType` 28: the allocator to use for objects (e.g., `std::allocator`) 29 30## Notes 31 32#### Default type 33 34With the default values for `ObjectType` (`std::map`), `StringType` (`std::string`), and `AllocatorType` 35(`std::allocator`), the default value for `object_t` is: 36 37```cpp 38// until C++14 39std::map< 40 std::string, // key_type 41 basic_json, // value_type 42 std::less<std::string>, // key_compare 43 std::allocator<std::pair<const std::string, basic_json>> // allocator_type 44> 45 46// since C++14 47std::map< 48 std::string, // key_type 49 basic_json, // value_type 50 std::less<>, // key_compare 51 std::allocator<std::pair<const std::string, basic_json>> // allocator_type 52> 53``` 54 55See [`object_comparator_t`](object_comparator_t.md) for more information. 56 57#### Behavior 58 59The choice of `object_t` influences the behavior of the JSON class. With the default type, objects have the following 60behavior: 61 62- When all names are unique, objects will be interoperable in the sense that all software implementations receiving that 63 object will agree on the name-value mappings. 64- When the names within an object are not unique, it is unspecified which one of the values for a given key will be 65 chosen. For instance, `#!json {"key": 2, "key": 1}` could be equal to either `#!json {"key": 1}` or 66 `#!json {"key": 2}`. 67- Internally, name/value pairs are stored in lexicographical order of the names. Objects will also be serialized (see 68 [`dump`](dump.md)) in this order. For instance, `#!json {"b": 1, "a": 2}` and `#!json {"a": 2, "b": 1}` will be stored 69 and serialized as `#!json {"a": 2, "b": 1}`. 70- When comparing objects, the order of the name/value pairs is irrelevant. This makes objects interoperable in the sense 71 that they will not be affected by these differences. For instance, `#!json {"b": 1, "a": 2}` and 72 `#!json {"a": 2, "b": 1}` will be treated as equal. 73 74#### Limits 75 76[RFC 8259](https://tools.ietf.org/html/rfc8259) specifies: 77> An implementation may set limits on the maximum depth of nesting. 78 79In this class, the object's limit of nesting is not explicitly constrained. However, a maximum depth of nesting may be 80introduced by the compiler or runtime environment. A theoretical limit can be queried by calling the 81[`max_size`](max_size.md) function of a JSON object. 82 83#### Storage 84 85Objects are stored as pointers in a `basic_json` type. That is, for any access to object values, a pointer of type 86`object_t*` must be dereferenced. 87 88#### Object key order 89 90The order name/value pairs are added to the object is *not* preserved by the library. Therefore, iterating an object may 91return name/value pairs in a different order than they were originally stored. In fact, keys will be traversed in 92alphabetical order as `std::map` with `std::less` is used by default. Please note this behavior conforms to 93[RFC 8259](https://tools.ietf.org/html/rfc8259), because any order implements the specified "unordered" nature of JSON objects. 94 95## Version history 96 97- Added in version 1.0.0. 98