On Mon, Sep 21, 2020 at 8:47 PM Hadriel Kaplan via Boost
I vote to ACCEPT Boost.JSON into boost.
Thank you for your time and thoughtful review.
Having yet another custom/purpose-built string implementation was surprising. It’s not an issue, but just surprising that yet another string type is being created.
I feel you here. What we want is a string type that has a very small sizeof(), and the same sizeof() across implementations of the standard library. And we want it to use the memory_resource / storage_ptr system that Boost.JSON offers. This of course rules out std::string. It is also nice to have a string type whose API is the same no matter what version of C++ is used.
It was also a bit surprising there wasn’t a function to pretty-print the serialized output (e..g, via an option arg for `serialize()`).
The current serializer prioritizes speed over anything else, but as the library matures we will of course see other options.
Boost.JSON has better performance and memory usage than some of the ones I know of
And this is an area of ongoing research and improvement - it will only get better!
unusual is frequently bad for interoperability.
Million dollar quote right here lol
Gcc doesn’t have pmr until version 9+, which is a shame ... I think being usable as standalone would increase the uptake for Boost.JSON… but requiring gcc 9+ negates that somewhat
Julien submitted a patch which is in develop and will get merged to master: https://github.com/CPPAlliance/json/commit/78c2bd301278bd9590b627451abcffe08... This makes Boost.JSON use std::experimental::pmr::memory_resource on gcc 8.3. Regards