New sematics for C++ copy assignment operataor?

[Robertlzw]

I came across with a book in which C++ copy assignment operator of a class becomes:

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

Is it correct? (I never saw anything like this, BWT)

[helios]

Yes, it's correct. The compiler doesn't look at the return type when comparing overloads, so that one will look identical to X &X::operator=(const X&);.

[zb0S216C]

---- [Notice: Post revoked] ----

_Wazzak

[andywestken]

Out of interest, which book?

I've always seen the member function version of operator= defined to return a non-const ref.

[Duthomhas]

Yes, what book?
I can't imagine why an assignment operator would return a const reference -- that does not make sense on several levels. (IMHO)

[Robertlzw]

Yes, the class X has a private pointer member if this information is important:

class Y;

class X {
public:
      const X &operator=(const X&);
private:
      Y *mPtr;
};

Based on my testing, it will not compile as the following:

class X x1, x2, x3;
(x1=x2)=x3;

Now I tend to believe that using const X &operator=(const X&); is quite wrong. Anyone think otherwise?

[andywestken]

Found this:

C++ why the assignment operator should return a const ref in order to avoid (a=b)=c
http://stackoverflow.com/questions/4706690/c-why-the-assignment-operator-should-return-a-const-ref-in-order-to-avoid-a-b

It's late here in London so I'll wait until I'm properly awake tomorrow.

[helios]

I have to say, I've never found myself in the situation where I just had to do (a=b)=c or (a=b).f().