Valid tive C ++ clause 11: In operator = handle 'self-assignment'

Suppose we create a class to save a bitmap with a pointer pointing to a dynamic allocation)

Class bitmap {...};
Class widget
{
Public:
Protected:
PRIVATE:
Bitmap * pb;
};

This operator = makes the Code look reasonable on the surface, but it is not safe when self-assignment occurs, and it does not have exceptional security.

Widget & Widget: Operator = (const widget & RHs)
{
Delete Pb;
PB = new Bitmap (* RHS. Pb );
Return * this;
}

RHS and * this may be the same object. In this case, delete will not only destroy the bitmap of the current object, but also destroy the bitmap of RHS.

The traditional method of pre-blocking this error is to verify the identity test at the beginning of operator =.

Widget & Widget: Operator = (const widget & RHs)
{// Verify the same test. If the test is self-assigned, no action is required.
If (this = & RHs)
{
Return * this;
}
Delete Pb;
PB = new Bitmap (* RHS. Pb );
Return * this;
}

"Exception Security" is not yet available. If "New bitmap" causes an exception (whether it is due to insufficient memory during allocation or the copy constructor of Bitmap throws an exception ), the widget will eventually have a pointer pointing to a quickly deleted bitmap.

Making operator = "exceptional security" often automatically returns "self-assigned security. As shown in the following code, do not delete petabytes before copying the content indicated by petabytes:

 

Widget & Widget: Operator = (const widget & RHs)
{
Bitmap * porig = Pb;
PB = new Bitmap (* RHS. Pb );
Delete porig;
Return * this;
}

In this case, if the new bitmap throws an exception, the Pb remains unchanged. It is not the most efficient way to handle self-assignment even if the same test is not proved, but it works. If you are concerned about efficiency, add "same verification test", but the test itself also requires costs, because the Code increases and a new control flow branch is imported, in addition, the frequency of "self-assignment" is not high.

An alternative solution to ensuring that the Code is not only "abnormal security" but "self-assigned security" is to use the so-called copy and swap technology:

Class widget
{
Public:
Void swap (widget & RHs); // exchange data of * This and RHS
Protected:
PRIVATE:
Bitmap * pb;
};

Widget & Widget: Operator = (const widget & RHs)
{
Widget temp (RHs );
Swap (temp );
Return * this;
}

Another variation of this topic: 1. The copy assignment operator may be declared as "accepting arguments by value"; 2. Passing something by value will produce a copy:

Widget & Widget: Operator = (widget RHs) // pass by value
{
Swap (RHs );
Return * this;
}

Make sure that operator = has good behavior when the object is assigned a value. The techniques include comparing the addresses of "source object" and "target object", carefully and thoughtful statement order, and

Copy and swap.

Determine if any function operates on more than one object, and if multiple objects are the same, its behavior is still correct.