Re: [boost] [variant] Please vote for behavior

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
>

Regardz ;-)
Neil Groves