On Fri, Jan 25, 2013 at 11:58 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Jan 25 2013, Neil Groves <neil-AT-grovescomputing.com> wrote:
I think variant after move is like int without initialization: int i; cout << i; // don't do this If the fact, that moved-from objects are only good for destruction or assignment-to is accepted, then invariants for moved-from objects are allowed to be violated.
I completely agree with the notion that a moved-from object simply should not be used in any manner.
Well, that's just wrong, for the non-destructive move model used by the
standard. The standard library relies on the ability to both assign and destroy moved-from elements. If you want destructive move, that's a whole research project. We on the committee who created rvalue references couldn't figure out how to make it work.
I think this comes down to my poor definition of use. I was thinking of "use" as apply public methods and mentally classifying assignment, copying, destruction as operations preparing objects for "use". I am somewhat confused about the move-from standardisation and will attempt to study this in more detail. My perception of this is that the object is in a rather new state and if I can't call public accessors and therefore their relationships no longer hold I think it could be argued that the class-invariants have been broken.
It is interestingly divergent from the typical Design by Contract idiom. It is much more usual, in my experience for the class-invariants to hold up to and including entry to the destructor
I don't understand what any of that means.
I'm sorry for not being clearer. From my understanding of DbC the class-invariants must hold upon entry and exit of public functions with the exceptions that the class-invariants may not hold upon entry into the constructors and upon exit of the destructor. Since I can no longer operate upon the object after it has been moved it seems we have a new "undefined state" that doesn't gel well with typical DbC application. As I stated previously I don't label this as bad. I label it as interesting.
It seems that this divergence is of little importance to users of the language since we are not explicitly interested in calling the destructor.
Indeed we are! Trying to keep track of which elements have been moved-from so you can avoid calling the destructor gets very hairy, very quickly. Again, we couldn't figure out how to do it.
It does indeed sound horrendously difficult.
If I understand correctly the standard is divergent
divergent from what?
My experience of DbC with Eiffel, D. I was simply referring to the odd state of the object where it is still 'live' yet cannot have public functions called despite the caller meeting pre-conditions. This seems to require an adjustment to the way one reasons about code albeit in a not particularly troublesome way.
to allow sensible compiler implementations of clean-up code for moved-from objects.
I don't understand what you're saying here, either.
I think I'm probably wasting your time. I should probably attempt to improve my understanding of the currently specified move semantics. I think while I do not understand the Rationale for allowing assignment and destruction of moved-from objects I am not in a position to make intelligent comments. I try to make that stop me from posting; sometimes I suffer the delusion that I actually understand things!
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Regardz ;-) Neil Groves