On Tue, Sep 24, 2019 at 7:32 AM Dominique Devienne
...why conflate the array and object APIs in the value type, rather than just having as_object() and as_array() as you already?
I agree, and these additional APIs have been pruned. I have also pruned other unnecessary APIs (thanks to advice from Peter Dimov) such as the local iterator and bucket interfaces in `json::object` (which needlessly constrain the implementation).
So I'm curious why it should be different here. Does the doc goes into that already?
`json::value` is not `variant<...>` for the same reason that
`string_view` is not `std::pair
On the "compact" side, how compact is your json::value? What are the different sizeof on 32 and 64-bit arch?
I've done some work on this. I gave up on using std::string to represent strings for a few reasons related to performance and API. I have reimplemented string to have a small buffer optimization and to work natively with the `json::storage_ptr` type which gives some space efficiencies (and eliminates some unnecessary atomic operations caused by std::string's Allocator interface). The new sizes look like this: 32-bit sizeof(value) == 40 sizeof(object) == 8 sizeof(array) == 8 sizeof(string) == 32 sizeof(number) == 24 64-bit sizeof(value) == 48 sizeof(object) == 16 sizeof(array) == 16 sizeof(string) == 40 sizeof(number) == 24 The string type has a 20-byte small buffer which is pretty generous Thanks