Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-06 09:14:57
sob., 6 kwi 2019 o 04:55 Larry Evans via Boost <boost_at_[hidden]>
> On 4/5/19 7:46 PM, Emil Dotchevski via Boost wrote:
> > On Thu, Apr 4, 2019 at 4:30 PM Gavin Lambert via Boost <
> > boost_at_[hidden]> wrote:
> >> The problem with transitioning to an otherwise valid but unexpected
> >> state is that it may end up evaluating unintended code
> > This is why I made the analogy with std::vector. Let's say you always put
> > exactly 10 elements in all your vectors, but then you assign one vector
> > another, and that fails, and now (unexpectedly?) you have an (otherwise
> > valid) vector with fewer than 10 elements.
> > Such is life. This is how the basic guarantee works, you get an
> > but valid state.
> >> (Granted, continuing evaluation on a faulted variable is already a bug
> >> in itself, but you are making detection of that bug harder by not
> >> putting the value into an obviously-faulted state.)
> > I do not think that it is a bug to access an object that is in a valid
> > state. In fact, the reason why the state is defined as valid is so that
> > can safely work with that object, even after a failure was reported.
> I'm guessing "unexpected" could mean the std::vector
> could have some arbitrary number of elements all filled with random
> values. I don't see how you can do anything useful with that.
Exactly. Of course, what you can do is to reset such object: call
`v.clear()` or assign a new vector whose state you know. And then you know
exactly what state it is in. But that's it.
The fact that an object in an unspecified state doesn't crash (or do random
things) when reading its value is not comforting at all: trying to read its
value is still something wrong.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk