Help for understanding the self assignment protection

[fl]

Hi,
I am new to C++. On C++ primer, 4th, page 601, the author said: (for
the below assignement function)
/////////////////
// use-counted assignment operator; use is a pointer to a shared use
count
Sales_item&
Sales_item:perator=(const Sales_item &rhs)
{
++*rhs.use;
decr_use();
p = rhs.p;
use = rhs.use;
return *this;
}
/////////////////
As usual with an assignment operator, we must protect against self-
assignment. This operator handles self-assignemnt by first
incrementing the use count in the right-hand operand. If the left- and
right-hand operands are the same, the use count will be at least 2
when "decr_use" is called. That function decrements and checks the use
count of the left-hand operand. If the use count goes to zero, then
decr_use will free the "Item_base" and "use" objects currently in this
object. What remains is to copy the pointers from the right-hand to
the left-hand operand. As usual, our assignment operator returns a
reference to the left-hand operand.
...........

My question is: I do not understand the paragraph and conclusion. I
agree that we must protect self-assignment. But, from the above
description, it seems that the above assignment function lacks self-
assignement now. That is, our assignment operator returns a reference
to the left-hand operand, but decr_use may free the "Item_base" and
"use" objects currently in this object.

If it requires self-assignment protection, how to do that? That book
talks the method about self-assignment protection? Please tell me if
you know that. Thanks a lot.

 

[Jerry Coffin]

[ ... ]

Sales_item&
Sales_item:perator=(const Sales_item &rhs)
{
++*rhs.use;
decr_use();
p = rhs.p;
use = rhs.use;
return *this;
}

[ ... ]

My question is: I do not understand the paragraph and conclusion. I
agree that we must protect self-assignment. But, from the above
description, it seems that the above assignment function lacks self-
assignement now. That is, our assignment operator returns a reference
to the left-hand operand, but decr_use may free the "Item_base" and
"use" objects currently in this object.

In self-assignment, the right hand and left hand sides refer to the same
object. This starts by incrementing the use count of the right hand
object. If this is a self-assignment, that increments the use count of
the left hand object, because it's the same object as the right hand
object. If it's self assignment, incrementing the right side increments
the use count then decr_use() decrements the same use count again -- but
since we just incremented it, the result is the same as it had been
previously.

If it requires self-assignment protection, how to do that? That book
talks the method about self-assignment protection? Please tell me if
you know that. Thanks a lot.

This doesn't really protect against self-assignment. It just makes sure
that nothing bad happens when self-assignment happens.

 

[James Kanze]

[...]

This doesn't really protect against self-assignment. It just
makes sure that nothing bad happens when self-assignment
happens.

Doesn't that depend on what is meant by "protect against
self-assignment". Taken literally, protect against
self-assignment would mean something like:
assert( this != &other ) ;
at the start of the assignment operator; I don't think that this
is what was meant, however.

As a general rule: it is preferable to acquire any needed
resources before modifying the actual value of the object---if
resource acquisition can fail, this is almost a necessity. If
you do this, you don't normally have to worry about
self-assignment---it just works. In the example we had here,
for example, the assignment operator first acquired the right
hand side object (by incrementing the use count), before
changing anything in its own representation. And
self-assignment just works. Similarly, an assignment operator
for an object which does a deep copy will new the new instance
before it deletes the old.