Returning a rvalue from function

How can you force a function to return a rvalue? I thought returning something by value would do that, but apparently this returns a lvalue:

Code:

---

MyClass MyClass::operator++(int)
{
        MyClass old(*this);
        ++(*this);
               
        return old;
}

---

Would this make it into a rvalue?

Code:

---

const MyClass MyClass::operator++(int)
{
        MyClass old(*this);
        ++(*this);
               
        return old;
}

---

In this case you can't return a lvalue (returning by value always makes the result a rvalue).

A lvalue would be a reference, for example:

Code:

---

MyClass& MyClass::operator++()
{
    //...
    return *this;
}

---

But I can do stuff like

Code:

---

MyObj++ = AnotherObj;

---

or

Code:

---

MyObj1 + MyObj2 = AnotherObj;

---

despite both + and ++ return by value.

The general guideline with operator overloading (for numeric types) is: do as int's do. Of the following, only the last one compiles:

Code:

---

int main()
{
    int a = 1, b = 2, c = 3;
    a + b = c; //a + b is not lvalue
    a++ = b;  //a++ is not lvalue
    ++a = b;  //++a is lvalue, but the whole expression is rather meaningless
}

---

Your examples would only compile if those operators violated that guideline and had really weird semantics.

But my postfix operator looks exactly like the one above (it returns by value), and I'm still able to do those things. What's going on?

Shouldn't this return a rvalue?

Code:

---

MyClass MyClass::operator++(int)
{
        MyClass old(*this);
        ++(*this);
               
        return old;
}

---

What you are posting is postincrement. Its return type is MyClass. What I posted was preincrement. Its return type is MyClass&.

Code:

---

a++ = b;

---

How do you think this should make sense?! Store value of a, increment a, then assign b to the stored value (what?).

I think you should stop thinking how you can make the result of postincrement a lvalue and instead describe the situation where you need it to be a lvalue. Are you getting a compiler error for some code?

No, I'm saying that I'm not getting any compiler errors when I do things like this with my postfix operator (code for it is above):

Code:

---

MyClassObj++ = AnotherMyClassObj;

---

I want it to return a rvalue since that's what it's supposed to do, but if the code above works that means it's returning a lvalue instead.

Basically: yes, if you want to disable such syntax, then returning a const value is correct. On the other hand, there may be cases where calling a non-const member function on the result of such an operation is elegant, and there is also the consideration that such abuse of syntax is rare.

So it's impossible to return a rvalue of class type? The other arithmetic operators that I have overloaded also return by value, and I can do crazy stuff like this:

Code:

---

obj1 + obj2 = obj3;
obj1 - obj2 = obj3;

---

Quote:

---

Originally Posted by Memloop

So it's impossible to return a rvalue of class type?

---

I am not certain enough to say yea or nay, but frankly it does not matter whether it is a case of returning an rvalue or returning a const lvalue as long as the interface you provide to your users works the way you want it to. Personally, I just return a non-const value by default since I consider such abuse to be corner cases.

Well the code example above is nonsensical so I would prefer if it wouldn't compile at all. I'm going the const route.

Quote:

---

Originally Posted by Memloop

So it's impossible to return a rvalue of class type?

---

No, you *are* returning an rvalue. The problem is that it's currently impossible to prevent calling the assignment operator of the rvalue that is returned. Unless you make the return type const, but as laserlight said, you might want to call a non-const function on the result directly. Also, making the return type const prevents moving from the rvalue you just returned in C++0x, and it might trip up some compilers' RVO.

All in all, I really suggest you *don't* make it const and simply rely on the fact that silly code like 'x++ = y' is pretty easy to spot.