Mdthbs

It is commonly known that when implementing an assignment operator one has to protect against self-assignment, at least when the class has non-POD members. Usually it is (or is equivalent to):

Foo& operator=(const Foo& other)

{

  if (&other == this)

     return *this;

  ... // Do copy

}

What were the reasons for not inserting the self-assignment protection automatically? Are there use cases when self-assignment does something non-trivial and practically useful?

Foo& operator=(const Foo& other)

{

  if (&other == this)

  {

    // Do something non-trivial

  }

  else

  {

    // Do copy

  }

  return *this;

}

Self-assignment protection is only necessary for types where the code being skipped is dangerous when applied to itself. Consider the case where you have a user-provided assignment operator because each individual object has some kind of identifier, which you don't want to copy. Well, you can "copy" the other values just fine in self-assignment cases. So inserting an invisible self-assignment test is just adding a pointless and potentially costly conditional branch.

So it's not about self-assignment being useful; it's about self-assignment not always needing protection.

Furthermore, C++ generally doesn't like adding code like that to your code without you explicitly asking for it. It's typically done in terms of whole functions, not part of functions. Even destructor calls at the end of blocks are something you asked for when you put the object to be destroyed on the stack.

There are algorithms where it can happen.

1. You know the lhs and rhs might be the same but it is just simpler to do the assignment than check. E.g., consider a = std::min(a,b); - simpler and perhaps easier to understand than if (a > b) a = b; - now consider more complicated examples of similar things.




2. You don't know whether lhs and rhs might be the same, because they may have been passed in from somewhere else.

These algorithms where it can happen are not uncommon.

I should admit I have never heard about the common knowledge like this. For a non-POD objects, a more strict approach is to forbid copying them with disabling copy constructor and the assignment operator. So that you don't have the problem at all.

If you still need to copy the class, but there is some data which is unsafe to copy to itself, you could only override assignment for that data, and when it is used as a field, it would be used by an automatic assignment implementation of the upper level class.

As for your question, if you only need to skip doing anything the automatic "self-assignment protection" is there already, in a way. If you don't define assignment operation explicitely and let compiler use the automatic one, after inlining self-assignment may become no-op.

For example, the following code:

class A {

    int a;

    double b;

};



A& foo(A& input)

{

    return (input = input);

}

is compiled to (gcc 4.9, -O2):

_Z3fooR1A:

    .cfi_startproc

    movq    %rdi, %rax

    ret

    .cfi_endproc

Which does not copy anything.