Subject: Re: [boost] Review request for variant2, review manager wanted
From: Peter Dimov (pdimov_at_[hidden])
Date: 2019-02-23 03:43:07
Niall Douglas wrote:
> 1. I need to know, from reading the documentation, what cost benefit there
> is to choosing this library over the major STL std::variant's,
The main cost/benefit gain over std::variant is that if you need to support
C++11 or C++14, std::variant doesn't work. :-)
> and Boost.Variant in these areas:
> a) Build time impact for small and medium sized variants doing a
> reasonable set of operations.
> b) Run time impact, for the same operations.
> c) Optional: also for large sized variants, just so we have evidence
> to prove to people don't do large sized variants!
> d) Optional: also compare to Outcome, I obviously have a vested
I may look into that, but it would help if you can give me some specific
scenarios which to measure; I prefer using realistic benchmarks over
> 2. I see that triviality of destruction is preserved, indeed half the
> variant header is just to implement triviality of destruction propagation.
Trivial destruction is mandatory for a literal type, and hence, for anything
> However the other individual operations do not have their triviality
> preserved, so for example if all the types in the variant have a trivial
> copy assignment but a non-trivial copy constructor, then so ought the
> variant. The same would go for noexcept-ness, if all the move assignments
> for all the types in the variant are noexcept, then so should be the
> variant's. And so on.
noexcept is preserved. Taking the copy constructor for example, when all
types are trivially copyable, the copy constructor is constexpr and
and when not, the copy constructor is noexcept when all are nothrow
This almost-triviality has all the benefits of real triviality except,
unfortunately, one - the ability for the type to be passed and returned in
So, yes, real triviality is something I will look into, at some point. Not
necessarily before the review though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk