From: Daniel Frey (d.frey_at_[hidden])
Date: 2019-10-22 22:13:07
> On 23. Oct 2019, at 00:00, Emil Dotchevski via Boost <boost_at_[hidden]> wrote:
> On Tue, Oct 22, 2019 at 2:53 PM Gavin Lambert via Boost <
> boost_at_[hidden]> wrote:
>> On 23/10/2019 05:25, Vinnie Falco wrote:
>>>> 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<char const*, std::size_t>`.
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk