On Wed, 8 Aug 2012, Dave Abrahams wrote:
Most uses of a moved-from object I can think of other than destruction and assignment are rather contrived. For a container, it can make sense to look at its size and assign to the elements. For a bignum, maybe if you are interested in an arbitrary number < y (to pass it to a nextafter-like function), before setting x to y-1, you could check if x<y and not want that to crash the program. If you are going to use a bignum as a bitfield, the same argument as for the container could be made.
This sounds kind of like programming with iostreams whose badbit has been set. Lots of times it's possible to write the code so that it can barrel ahead as though nothing is wrong and only check for a problem much later. But it sounds kind of implausible that you'd be able to pick a value for empty bignums that would allow that in most or even many cases.
Hi Dave, I am not sure what you mean here. The safe solution is that whenever you move-construct from a bignum, you set it to zero (move-assignment is a swap). I am not sure, but it sounds like you are saying this wouldn't be safe? The issue here is that setting it to zero is expensive (less than a copy, but still quite a bit), so John instead decided to put it in some "broken" state that he can detect at destruction/assignment time. This means that doing x-y or x<y may crash (although if he sets _mp_size to 0, most read operations are likely not to notice that this isn't a true zero). This is probably a good compromise: better performance for regular code, crashes only for very odd code. The question is where the limit is between regular and odd code... -- Marc Glisse