Hello,

5.17.1 specifies that the left operand of a copy assignment should be an
lvalue, yet the following does compile on gcc and comeau. Can anyone
shed light on this?

Cheers,

Jens


struct x { };

x foo() { }

int main()
{
   foo() = foo();
   x() = x();
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

* Jens Theisen:
>=20
> 5.17.1 specifies that the left operand of a copy assignment should be a=
n=20
> lvalue, yet the following does compile on gcc and comeau. Can anyone=20
> shed light on this?

=A75.17/1 refers to the built-in assignment operators.


> struct x { };
>=20
> x foo() { }

Undefined behavior: missing return.


> int main()
> {
>   foo() =3D foo();
>   x() =3D x();
> }

Try (the untried code ;-) )

   struct S { void foo() const {} };

   S bar() { return S(); }

   int main()
   {
       S().foo();
       bar().foo();  // Aha, you can call a member function on a temp.

       S().operator=3D( S() );
       bar().operator=3D( S() );    // Even auto-generated functions.

       S() =3D S();    // Guess what this is translated to?
   }

However, the standard is somewhat inconsistent, for if you try to assign=20
to a built-in type data member of an S temporary, then you're up against=20
=A75.17/1.  So we have a case where you can assign to the struct (and let=
=20
it be a POD struct) as a whole, but not to a data member of that struct.=20
  That's been discussed before, but as far as I can recall with no clear=20
consensus; the problem is that there are many possible resolutions.

And btw., I've had to change my opinion/understanding of this, not long=20
ago (months, not years).

It simply isn't very intuitive.

--=20
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alf P. Steinbach wrote:
> =A75.17/1 refers to the built-in assignment operators.

Which is something different as an auto-generated one, I see. The=20
auto-generated ones yield lvalues.

> However, the standard is somewhat inconsistent, for if you try to assig=
n=20
> to a built-in type data member of an S temporary, then you're up agains=
t=20
> =A75.17/1.  So we have a case where you can assign to the struct (and l=
et=20
> it be a POD struct) as a whole, but not to a data member of that struct=
.=20
>  That's been discussed before, but as far as I can recall with no clear=
=20
> consensus; the problem is that there are many possible resolutions.

Yes, gcc accepts it all, comeau doesn't:

struct x {
   int y;
   x & operator =3D (x const& x);   // like the implicit one
   x & self () { return *this; }
};

x foo() { return x(); }

int main()
{
   foo().y =3D 2;               // comeau says no
   foo().self().y =3D 2;        // comeau says yes
}

That's weird.

Thanks very much!

Jens

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]