Subject: Re: [boost] several messages
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-08-09 20:46:30
On Thu, Aug 9, 2012 at 8:22 AM, John Maddock <boost.regex_at_[hidden]> 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.
> 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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk