Boost logo

Boost :

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Peter Dimov (lists_at_[hidden])
Date: 2019-03-01 00:16:34

Andrzej Krzemienski wrote:
> Hi Peter,
> Thank you for writing and sharing this implementation of variant.
> I am sorry if I am bringing back an issue that has been already discussed
> and solved before, but I do not understand the rationale behind doing
> compromises in order to provide the never-empty guarantee.
> The short rationale provided in Boost.Variant library:
> was provided before we got C++11 the moved-from state in the language.
> Today, it should come as no surprise to programmers that a type might be
> in a "moved from" state where only a limited interface of an object can be
> used.

C++11 introduces no such "moved-from" state. After a move, objects are not
in a special state. The desire to have variant<X, Y, Z> contain one of X, Y,
or Z, is as valid today as it was when Boost.Variant was developed.

> The guarantee provided by variant's assignment is not a strong exception
> safety guarantee: it is possible that my variant has value A, I want to
> assign value B, and (due to an exception) I end up with value C.

That's correct. Strong guarantee requires double buffering when two or more
of the alternatives have a throwing move constructor. This would affect
significantly more of the real-world cases than the current scheme, which
doubles only occasionally.

> If this happens, the only thing I can reasonably do is to either abandon
> whatever I was doing or reset the variant to the state that I need. So the
> guarantee that it is not left empty does not seem to be of much use. But
> the cost to be paid is noticeable.

Well, if you want a variant without this guarantee, there are plenty to be
found. Those who don't, however, have no options at present.

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