Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2019-03-02 18:40:04
On 3/2/19 11:25 AM, Niall Douglas via Boost wrote:
>>> Thus I would hold that, unless there is a *very* good reason why not, so
>>> should std::variant propagate the strong guarantee where it is able to
>>> do so. To my knowledge, there is no good reason that is does not, as
>>> proven by Peter's variant2.
>> Hold on. Most standard library types *do not* provide strong exception
>> safety guarantee on assignment. It is only the subset of STL containers
>> that are implemented as pointers, such as std::vector or std::list.
> You see, I would consider any union-based storage as in the same
> category. By definition union-based storage must contain a "pointer" to
> the correct way to interpret that union-based storage.
I don't understand this. Andrzej says pointers and
means it literally: T*. You say "pointers" and
I have no idea what you mean by it and what relation
it has to exception safety.
>> variant2 also only provides *basic* exception safety guarantee: you can be
>> assigning a variant containing type B to a variant containing type A and
>> end up with variant containing type C. Here's an example:
> I just don't get why variant2 would set a state of C when it had state
> A, and setting state B failed. It should have spotted the lack of common
> noexcept move, employed double buffers, and alternated between them such
> that state A is untouched should setting state B fail.
> If it's going to do weirdness like setting state C out of the blue, then
> better dispose entirely any double buffered implementation as not adding
variant2 won't use double buffering in this example.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk