sob., 6 kwi 2019 o 04:55 Larry Evans via Boost
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@lists.boost.org> 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 to 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 unspecified 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 you 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. Regards, &rzej;