Re: [boost] New JSON library from the maker of Beast!

On 23. Oct 2019, at 00:00, Emil Dotchevski via Boost wrote:

On Tue, Oct 22, 2019 at 2:53 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:

...

...

...

So I'm curious why it should be different here. Does the doc goes into

On 23/10/2019 05:25, Vinnie Falco wrote: that already?

...

`json::value` is not `variant<...>` for the same reason that `string_view` is not `std::pair`.

That's a good reason for not inheriting from it.

It's not a good reason for not using it as a private member, to avoid reimplementing the variant-storage concept. (Though there may be other good reasons for that.)

There are always two kinds of dependencies, logical and physical. Logically, you use something as a private member, you're ok, but physically you're still dependent on it, and that may be a problem. Further, std::variant may be problematic for portability, and it may or may not be as efficient as something hand-written specifically for the purpose. Consider that if performance is critical, you don't want to deal with "I changed my compiler and now your JSON parser runs 2x slower".

That sounds like you should stop using the STL altogether. What if std::string is suddenly 2x slower? So... no, I don't buy that argument. I just switched our JSON library https://github.com/taocpp/json from our own classic enum+union implementation (back from the C++11 days) over to std::variant (as we are now C++17 anyways). It saves us about 800-1000 LOCs and I ran benchmarks with GCC and Clang as well as libstdc++ and libc++. They were all equally fast or even faster. Admittedly I only used the newest versions of those and I haven't tested MSVC, but given the quality of MSVC in the last years I am not worried about the performance at all. If something is slow, more people using it will only create more incentives for the STL maintainers to improve their implementations further.