mardi 4 octobre 2016

What is the rationale for self-assignment-unsafe move assignment operators in the standard library?

The standard library policy about move assignment is that the implementation is allowed to assume that self-assignement will never happen; this seems to be a really bad idea, given that:

  • the "regular assignment" contract in C++ has always required to be safe against self-assignment; now we have yet another incoherent corner case of C++ to remember and to explain - and a subtly dangerous one, too; I think we all agree that what is needed in C++ is not more hidden traps;
  • it complicates algorithms - anything in the remove_if family need to take care of this corner case;
  • it would be really easy to fulfill this requirement - where you implement move with swap it comes for free, and even in other cases (where you can get some performance boost with ad-hoc logic) it's just single, (almost) never taken branch, which is virtually free on any CPU.

So, why such a decision?

Aucun commentaire:

Enregistrer un commentaire