Subject: Re: [boost] [variant2] documentation request
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2019-03-05 01:18:26
On 3/4/19 5:44 PM, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> You seem very wedded to not breaking out single_buffer_variant and
>> double_buffer_variant Peter. You seem keen we should accept your
>> mix of when each ought to be employed using your hardcoded logic. Can I
>> ask why?
> I don't have a good answer to this question. Breaking out into two separate
> classes per number of buffers seems sensible and straightforward, and I
> don't have any waterproof arguments against it apart from the fact that I
> intuitively dislike it.
I know why I dislike it. It exposes low level
details of the implementation which most users
should neither know nor care about. If someone
asks for a single buffered variant, what he really
means, is "I really care about performance. Give
me a hard error instead of using more space."
double_buffered_variant, really means "give me
strong exception safety. I don't care about the cost."
Exposing single_buffered_variant and double_buffered_variant
effectively rules out other possible compromises. For
example, if all the types without no-throw move are
smaller than the largest type in the variant, then
you can save space with a partially double buffered
> I prefer having a single variant, named "variant", which is almost always a
> drop-in replacement for std::variant, for the fairly obvious reason that
> it's easy to recommend to users: just use variant2::variant instead of
> std::variant, and your problems will be gone (not valid in all
> jurisdictions) and (b) it would be possible, in theory, to one day replace
> std::variant with it.
> For people who'd rather have single_buffer_variant<T...>, I can provide a
> static constexpr member function `bool
> which they can static_assert. So
> template<class... T> using single_buffer_variant =
> Â Â mp_if_c<variant<T...>::is_single_buffered(), variant<T...>>;
> To those who'd rather have double_buffer_variant, though, I don't have a
> good offer.