|
Boost : |
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.
>>
>
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk