On Thu, Aug 9, 2012 at 8:22 AM, John Maddock <boost.regex@virgin.net> wrote:
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.
IMHO any code that reads such unspecified values is buggy.
Right.
I wonder if the compiler could produce warnings for reading an
unspecified value. It seems like a bad idea 99.9% of the time. It'd be cool if Valgrind could be given a hint to mark such data as non-inited.
If I had a movable class with a double I'd set it's value signaling NAN at least for a debug build.
Currently, any attempt to "use" a moved-from value results in an assertion, the only things you can safely do are destruct, assign-to, swap, or copy such values.
There is a slight inconsistency though - not all number type Backends support (or need to support) move semantics. So if you switch from a fixed precision integer which simply copies (no move), to an arbitrary precision integer (moves) then you get a change in behavior. Of course any code that relies on an object having a specific value after it's been moved was IMO buggy to begin with, it's just that you might not see the asserts until you test with a move-enabled type. This is unfortunate, but I really don't want to hobble the fixed precision integers by giving them a special singular state (more code more checking), when most of the negative review comments were of the opinion that they're too heavyweight already.
John.
I'd go even further and just say it's undefined behavior...you should say "if you're lucky, it'll assert", and maybe explain how the backends affect behavior in the present implementation, but I wouldn't go so far as to guarantee it. - Jeff