Fredrik Eriksson wrote:
> Specifically, they facilitate move constructors 
> which are much like copy constructors except that they may destructively 
> alter the source of the "copy".

One of my problems with learning C++ is the number of places where, 
instead of saying "This is what this feature does", people say "this is 
how you use this feature."  (Not unlike Perl, where there are all these 
defaults that nobody uses because they're too complex to remember. :-)

What is a "move constructor"? When would you be "moving" some value? If 
you destructively alter something with aliases, aren't you in trouble? 
Isn't that what the whole "ownership" concept is supposed to prevent?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Tue, 02 Sep 2008 22:22:46 +0200, Darren New <dne### [at] sanrrcom> wrote:
> One of my problems with learning C++ is the number of places where,  
> instead of saying "This is what this feature does", people say "this is  
> how you use this feature."

Perhaps because the rules are sometimes so complex that few really know  
exactly what a particular feature does under all conditions. It is much  
easier to say "if you do it like this, it works" than to list all the many  
cases where it does something slightly or vastly different.



> What is a "move constructor"? When would you be "moving" some value?

"Moving" a value is useful when you know that the source value will be  
discarded anyway right after the copy is performed, e.g. if it is the  
return value of a function. Many objects that are expensive to copy can be  
"moved" much more efficiently.

Also, some types of objects are inherently non-copyable -- because they  
hold/represent some unique resource -- but they could still be "movable".



> If you destructively alter something with aliases, aren't you in trouble?

Hence the need to distinguish temporaries from regular const objects. Note  
that non-temporaries can also be bound to r-value references, but not  
implicitly.



> Isn't that what the whole "ownership" concept is supposed to prevent?

A move constructor would transfer ownership of whatever the source object  
is holding. Look to 'std::auto_ptr' for something resembling an example.




A more verbose summary can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html


-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> On Tue, 02 Sep 2008 22:22:46 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> One of my problems with learning C++ is the number of places where, 
>> instead of saying "This is what this feature does", people say "this 
>> is how you use this feature."
> 
> Perhaps because the rules are sometimes so complex that few really know 
> exactly what a particular feature does under all conditions. It is much 
> easier to say "if you do it like this, it works" than to list all the 
> many cases where it does something slightly or vastly different.

Yeah, basically.  "We don't actually know what the semantics are. We 
just all know the idioms for using the feature."

>> What is a "move constructor"? When would you be "moving" some value?
> 
> "Moving" a value is useful when you know that the source value will be 
> discarded anyway right after the copy is performed, e.g. if it is the 
> return value of a function. Many objects that are expensive to copy can 
> be "moved" much more efficiently.

But the rvalue thing doesn't move a value. What does the rvalue thing 
actually *do* that's different from anything else?  Isn't it that it 
points to a temporary with a guarantee of no aliases?

> Note that non-temporaries can also be bound to r-value references, but 
> not implicitly.

Well, yes, because C++ lets you break anything. That's not the point, 
tho. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Tue, 02 Sep 2008 23:16:45 +0200, Darren New <dne### [at] sanrrcom> wrote:
> But the rvalue thing doesn't move a value. What does the rvalue thing  
> actually *do* that's different from anything else?

It lets you distinguish objects whose values will soon be discarded anyway  
 from objects whose values may not be tampered with.



> Isn't it that it points to a temporary with a guarantee of no aliases?

Aliasing is not the issue. Expected lifetime is.



>> Note that non-temporaries can also be bound to r-value references, but  
>> not implicitly.
>
> Well, yes, because C++ lets you break anything. That's not the point,  
> tho. :-)

It is useful when you need to shuffle values around, but you do not want  
to pay the price of copying them.



-- 
FE

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> What is a "move constructor"? When would you be "moving" some value? If 
> you destructively alter something with aliases, aren't you in trouble? 
> Isn't that what the whole "ownership" concept is supposed to prevent?

  I explained this to you some time ago.

  Suppose you have two 1000x1000 matrices, A and B, and you do this:

Matrix C = A + B;

  The result of operator+ is a nameless temporary which will be destroyed
after the ';'. What that line is doing is initializing C with the value of
that temporary (before it's destroyed).

  What move semantics allow is for the constructor of C to grab the huge
1000x1000 array from the temporary, ie. move it to itself, rather than
copying it (the constructor of C does this by eg. copying the array pointer
from the temporary and assigning null to the pointer in the temporary). When
it has moved the array to itself, the nameless temporary has only a null
pointer, which the destructor of the Matrix class will delete, but deleting
a null pointer is a no-op. Thus nothing is destroyed (except the nameless
temporary Matrix object).

  It's safe for C to do that because it knows that the parameter is a
temporary, nothing points to it, and it's the sole owner of its array.
Nothing will get broken if C just moves the array from the temporary to
itself.

  In the current C++ doing such a move constructor is impossible: There's
no way of knowing if the parameter is a temporary or not.

  What the new C++ standard will add is a way creating a function (eg. a
constructor) which is called when a temporary is given to it as parameter.
This is achieved with the so-called rvalue references. A function taking
an rvalue reference knows that the parameter is a temporary, and thus it's
completely safe to modify it, allowing move semantics to be implemented.

  Move semantics have many useful purposes. For example they make it much
easier to safely return a dynamically allocated object as the return value
of a function, without having to go through the trouble of implementing
reference counting. (The new standard will actually include a one-owner
smart pointer which has move semantics, similar to the current auto_ptr,
but much safer.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I explained this to you some time ago.

Yes. I wanted to rephrase it so I was sure I understood.

>   It's safe for C to do that because it knows that the parameter is a
> temporary, nothing points to it, and it's the sole owner of its array.

Yes, that's kind of what I was asking.

I see where I went wrong. When I said "guaranteed not to be aliased", I 
was implicitly implying (in my head rather than out loud) the 
"temporary" part, and that confused people trying to help me. I should 
have said "a temporary guaranteed not to be aliased."

I mean, the important part is that it isn't and will never be accessed 
by something else later, so it's OK to corrupt it; that temporaries are 
the obvious place where the compiler can tell this is the case is 
secondary, yes?

Sorry for seeming dense.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On 7 Aug 2008 13:04:00 -0400, Jim Henderson wrote:
> On Thu, 07 Aug 2008 13:02:33 -0400, Warp wrote:
>
>>   I always got the impression that COBOL was the "BASIC" of the 70's,
>
> Try the 60's. ;-)

And Lisp was the Haskell of 60-70s?
It was developed in 1958. Wow, that seems awfully early
for a language with such high level concepts.
And they say, any new high level language concepts devised
in today's modern languages are merely imitations of
what Lisp has had already for ages.

-- 
Joel Yliluoma - http://iki.fi/bisqwit/

Post a reply to this message