Subject: Re: [boost] [variant2] Andrzej's review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-15 08:22:20
sob., 13 kwi 2019 o 17:34 Peter Dimov via Boost <boost_at_[hidden]>
> Niall Douglas wrote:
> > I just do not understand the antipathy here to a
> > double-buffered-by-default design, and thus the strong guarantee can be
> > easily made, rather than a worse-than-useless basic guarantee which is
> > only technically valid, but is certainly surprising.
> First off, the basic guarantee isn't worse than useless, it's the minimum
> standard that every non-broken component must meet, and everyone who
> otherwise isn't worth listening to.
> With that out of the way, though, variant2 may end up with the strong
> guarantee anyway, for other reasons. Consider this example:
> variant<X, std::vector<X>> v;
> v.emplace<1>( 1 );
> v = get<1>( v )[ 0 ];
> (a variation of which Antony Polukhin reported some time ago as a
> defect in std::variant, if I'm not mistaken.)
> What happens here is that on the last line, `v` on the left owns the `X`
> value on the right. So when the implementation first destroys the old
> contents of `v` to make room for the new `X`, the right hand side is
> destroyed, and then undefined behavior occurs when we try to copy it into
> This is fixable. But when we fix it, we've paid much of the price required
> for the strong guarantee, so we might as well offer that.
> With respect to this example, there're the usual two schools of thought,
> saying it's the user's fault, don't penalize my variant for that, the
> preferring variant handle it. I'm trending towards the latter camp.
Whatever the decision, it is worth keeping this characterization in mind:
this is two schools of thought. It should never disappear from the library
documentation: in which favor do we resolve the trade-offs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk