Thread: returning a const reference

I've seen people overload an assignment operator this way

Code:

class My_class {
public:
  My_class() {}

  My_class(int i) : data(i) {}
  
  int get_data() const {
    return data;
  }
  
  void set_data(int i) {
    data = i;
  }
  
  const My_class& operator =(const My_class& my_class_obj) {
    data = my_class_obj.data;
    return *this;
  }

private:
  int data;
};

and it seems pointless, but I haven't been able to find a definitive answer -- is there any situation in which you would want the return type of = to be const My_class& (or even a situation in which this "constness" has any effect)?

I see that, but it's puzzling. Ordinarily, the effect of (a = b) = c seems to be the same as

Code:

a = b;
a = c;

and using any const b on the rhs of a = b doesn't "constify" a,
and (a = b) doesn't "look like" it should be a valid l-value anyway, so ...
it would seem that either (a = b) = c should be treated the same as two sequential assignments, in which case the const return type of the assignment operator would have no effect, or statements of the form (a = b) = c should simply be illegal.

Is there something wrong with my reasoning?

No, your reasoning is perfect here. Let me quote you:

and (a = b) doesn't "look like" it should be a valid l-value anyway, so ...

Exactly! That's why you const it. Now, if the coder uses it as l-value, it produces an error. If you didn't, it would've been a valid l-value.

Why would you want that? Well, if you want to override the operator= to do something else than assignment, it may make sense. Just as streams use << and >>, which have nothing in common with bit shifting.

Ah! I guess my thinking is too rigid. It never occurred to me that = might do anything other than assignment or testing equality.

Thank you both.

That's exactly why I was suggesting that it should simply be treated as invalid syntax.

I agree, it wouldn't be very good design. But it might still be wanted. For instance if a programmer overrides operator= to send something to some hardware port. Now, if a programmer wants to write both a and b to the port he can write "(port = a) = b".

It would be terrible. And any situation you might want such a construct I can think of would be terrible. But I think it's still good that C++ allows you to do such things just in case.