move semantics / rvalue references

just now looking into this. not sure if i'm doign it wrong. a sanity check would be much appreciated.

Code:

---

Matrix&& Matrix::operator +(const Matrix& b)const
{
    Matrix result(*this);
    result+=b;
    return (Matrix&&)result;
}

Matrix::Matrix(Matrix&& rhs):
  data(rhs.data),
  rows(rhs.rows),
  cols(rhs.cols)
{
}

void foo()
{
  Matrix a;
  Matrix b;
  Matrix aPlusB(a+b);
}

---

edit: ok it seems like i am definitely missing the point. this is the usage case i'd like to accomodate: using arithmetic operators on matrix operations without any extraneous copies. if someone can assist in disabusing me of my ignorance that would be fantastic.

thanks.

the addition operator is often implemented as a free function, and as a friend to the class upon which it acts.

also, instead of copying or moving *this, you should just create a local reference like so:

Code:

---

Matrix& result = *this;

---

i don't really get what you're saying...result is a new matrix and i don't want to modify this

Code:

---

Matrix::Matrix(Matrix&& rhs):
  data(std::move(rhs.data)),
  rows(std::move(rhs.rows)),
  cols(std::move(rhs.cols))
{
}

Matrix aPlusB(a+b); //aPlus is moved from the temp object.

---

evidently return (Matrix&&)result still returns a dangling reference - that seems to be the problem. is RVO sufficient to optimize this usage case? what i'm reading seems to suggest it is. i've previously noticed that neither the copy ctor nor the assignment operator is invoked, so that would make sense

es, it is "dangling" reference that return a reference to a local object.
The copy constructor of Matrix would not be invoked, because you give a move constructor. But the move constructor you defined is not really "move sematics", becuase its members are copy constructed, so you have to use std::move() to transform the members of rhs into rvalue.

i think i'm getting it...

Code:

---

class Foo
{
private:
    class Bar
    {
       
    };
    Bar* bar
public:
    Foo():
        bar(new Bar())
    {
    }

    Foo(Foo&& rhs): 
        bar(std::move(rhs.bar))
    {
        rhs.bar = nullptr;
    }
    ~Foo()
    {
        if(bar) delete bar;
    }
};

---

yes, but it is not necessary using std::move() with bar, because bar is a POD type.

In fact, move constrictor is not a substitute for copy constrcutor. Don't forget copy constrictor if there is a deep copy.

You return locals by value, and if there is a move constructor, this will be invoked to move the result to the caller.

Quote:

---

Originally Posted by anon

You return locals by value, and if there is a move constructor, this will be invoked to move the result to the caller.

---

excellent. thank you. i had inferred this from what compiled, but wasn't sure if that was correct.

so move constructors will move something off the stack into the heap, or into a scope in the stack?

A move constructor is a constructor that takes a reference to a temporary object; nothing more, nothing less.
Previously we could only use const references to temporary objects.
Using the new move constructor, the goal is to "steal" the resources from the temp object. Don't forget to properly "remove" the resources from the temporary (like settings pointers to nullptr) to ensure it doesn't destroy them.

Remember it's still a reference, and you can't return a reference to a local variable!

thanks everyone. this is proving to be particularly useful for my current purposes - wrapping native matrix code optimized for SIMD / GPGPU for .NET.