Are temporary C++ objects lvalues?

Question

I'm puzzling over the following code, which (surprisingly, to me) compiles:

class A {
  int a=0;
};

A returnsA(void)
{
  static A myA;

  return myA;
}

void works(void)
{
  A anotherA;

  returnsA() = anotherA;
}

I can't find anything in the standard or on the web which suggests that it shouldn't compile. It just seems very weird, to me.

I guess returnsA() is returning an object (a copy of myA), so we invoke the default copy assignment operator on it, anotherA gets copy-assigned to the returned object, which then goes out of scope and is destroyed.

I was expecting behavior more like this, which doesn't compile:

int returnsint(void)
{
  static int i=0;

  return i;
}

void doesntwork(void)
{
  int anotherint=0;

  returnsint() = anotherint;
}

Can anybody enlighten me further about this behavior?

Relevant? Maybe dupish https://stackoverflow.com/q/51172341/817643 — StoryTeller - Unslander Monica, Sep 25 '18 at 04:32
@StoryTeller Yep, it's using the implicitly defined copy assignment operator. Quite legal. — doug, Sep 25 '18 at 04:38
@P.W, is the storage specifier static? I'm returning a copy of myA, not myA itself, right? — Brent Baccala, Sep 25 '18 at 04:39
@P.W It passes a copy of the static object. The fact it's static isn't relevant. — doug, Sep 25 '18 at 04:39
I'm actually more surprised that the int version is not legal than that the class version is. (I would have expected the int version to be completely useless but still legal). — SoronelHaetir, Sep 25 '18 at 04:42
The code in the question body has nothing to do with the title — M.M, Sep 25 '18 at 04:42
@M.M The OP's confusion is based on the idea you can't do a copy assign to an rvalue. But you can, just not to native rvalues. — doug, Sep 25 '18 at 04:44
Another useful Q&A in this context. https://stackoverflow.com/questions/9493923/c11-why-is-assigning-rvalues-allowed — P.W, Sep 25 '18 at 04:48

score 5 · Accepted Answer · answered Sep 25 '18 at 04:48

Objects are not lvalues or rvalues. The words lvalue and rvalue are expression categories. They categorize expressions, not objects.

For the line:

returnsA() = anotherA;

since the operands of = are class types, an overloaded operator function is searched for. operator= is special in that if the user does not explicitly overload it, there is a default overload generated. That overload is a member function with signature:

A& A::operator=(A const&);

and the call returnsA() = anotherA; is transformed to returnsA().operator=(anotherA);, this is the basic mechanics of member operator overloading.

The expression returnsA() has category prvalue. However it is perfectly fine to call member functions on prvalue expressions, so there is no problem here.

If you want to dissuade your class from accepting this sort of assignment, see here. And for why the default assignment operator doesn't work that way, see here.

Did you mean "Objects may be either lvalues or rvalues?" They are either one or the other. You even pointed out the `returnsA()` yields a prvalue. — doug, Sep 25 '18 at 05:11
@doug no, I meant what I said. Objects are not expressions, expressions are not objects. Those are different concepts. `returnsA()` *is* a prvalue expression (it does not "yield" a prvalue). Executing this expression *might* cause materialization of a temporary object, but the expression is not the object and vice versa. — M.M, Sep 25 '18 at 05:34

Are temporary C++ objects lvalues?

1 Answers1