Subject: Re: [boost] [variant] Please vote for behavior
From: Neil Groves (neil_at_[hidden])
Date: 2013-01-25 20:21:22
On Fri, Jan 25, 2013 at 11:58 PM, Dave Abrahams <dave_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk