Boost logo

Boost :

Subject: Re: [boost] several messages
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-08-08 14:09:16


on Tue Aug 07 2012, Marc Glisse <marc.glisse-AT-inria.fr> wrote:

> On Sun, 5 Aug 2012, John Maddock wrote:
>
>>> I believe Marc is correct. You must be able to destruct *and* assign-to a
>>> moved-from object.
>>
>> Just checked the std and you're both correct.
>>
>> OK I'll have to rethink, and make sure everything other than
>> arithmetic is supported for moved-from types.
>
> Actually, in principle, a moved-from object should be a valid object,
> which just has an unspecified value. But computing x-x should be
> legal, unless it is documented that the type has a valid singular
> state (accessible by being moved from or swapped (=move-assigned)) and
> that all operations other than assignment have a precondition that the
> arguments are not singular. And then it is strange not to have a way
> to test if a value is singular.

This is a very good summary.

> 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.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk