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.