Boost logo

Boost :

Subject: Re: [boost] [variant2] documentation request
From: Gavin Lambert (boost_at_[hidden])
Date: 2019-03-04 05:28:27

On 4/03/2019 10:43, Peter Dimov wrote:
> Niall Douglas wrote:
>> This is why I would suggest variant2 provide elemental
>> single_buffer_variant and double_buffer_variant, and let the end user
>> choose which they want.
> variant2 presently is single_buffer_variant except that instead of
> giving you an error when that's not possible, it silently switches to
> double_buffer_variant and soldiers on. (Which happens rarely.)

I dislike in general silent implementation switches that can have
performance consequences that can be triggered by a typo or a forgetful
lack of "noexcept" modifier.

> I agree that one can make a good argument for (a variation of)
> double_buffer_variant, which prioritizes strong guarantee over sizeof.
> But that's only needed when your contained types don't have noexcept
> move. In this case, a not unreasonable course of action is to hold them
> by unique_ptr in the variant instead.

How hard would it be to publicly provide single_buffer_variant,
double_buffer_variant, and variant (where the latter is just an
intelligent alias to one of the other two based on the argument types,
as per your current rules)?

That would let consumers who care explicitly indicate that they don't
want double-buffering -- and then get a compile error if they
inadvertently put an incorrect type in, rather than getting unintended

(I'm less sure if there's a use case for explicitly wanting
double-buffering always, but it seems easier to provide it than not to,
if you have to write a double-buffered version anyway.)

But the alias means that consumers who don't care, don't have to.

Boost list run by bdawes at, gregod at, cpdaniel at, john at