为类数据成员调用副本构造函数和operator =

Question

Below is an example code (for learning purpose only). Classes A and B are independent and have copy contructors and operators= .

class C
{

public:
   C(string cName1, string cName2): a(cName1), b(new B(cName2)) {}
   C(const C &c): a(c.a), b(new B(*(c.b))) {}
   ~C(){ delete b; }
   C& operator=(const C &c)
   {
      if(&c == this) return *this;

      a.operator=(c.a);

      //1
      delete b;
      b = new B(*(c.b));

      //What about this:
      /*

      //2
      b->operator=(*(c.b));

      //3
      (*b).operator=(*(c.b));

      */

      return *this;
   }

private:
   A a;
   B *b;

};

There are three ways of making assignment for data member b. In fact first of them calls copy constructor. Which one should I use ? //2 and //3 seems to be equivalent.

Answer 1

I decided to move my answer to answers and elaborate.

You want to use 2 or 3 because 1 reallocated the object entirely. You do all the work to clean up, and then do all the work to reallocate/reinitialized the object. However copy assignment:

*b = *cb;

And the variants you used in your code simply copy the data.

however, we gotta ask, why are you doing it this way in the first place?

There are two reasons, in my mind, to have pointers as members of the class. The first is using b as an opaque pointer. If that is the case, then you don't need to keep reading.

However, what is more likely is that you are trying to use polymorphism with b. IE you have classes D and E that inherit from B. In that case, you CANNOT use the assignment operator! Think about it this way:

B* src_ptr = new D();//pointer to D
B* dest_ptr = new E();//pointer to E
*dest_ptr = *src_ptr;//what happens here?

What happens?

Well, the compiler sees the following function call with the assignment operator:

B& = const B&

It is only aware of the members of B: it can't clean up the no longer used members of E, and it can't really translate from D to E.

In this situation, it is often better to use situation 1 rather than try to decern the subtypes, and use a clone type operator.

class B
{
public:
  virtual B* clone() const = 0;
};

B* src_ptr = new E();//pointer to D
B* dest_ptr = new D();//pointer to E, w/e
delete dest_ptr;
dest_ptr = src_ptr->clone();

Answer 2

It may be down to the example but I actually don't even see why b is allocated on the heap. However, the reason why b is allocate on the heap informs how it needs to be copied/assigned. I think there are three reasons for objects to be allocated on the heap rather than being embedded or allocated on the stack:

1. The object is shared between multiple other objects. Obviously, in this case there is shared ownership and it isn't the object which is actually copied but rather a pointer to the object. Most likely the object is maintained using a std::shared_ptr<T> .
2. The object is polymorphic and the set of supported types is unknown. In this case the object is actually not copied but rather cloned using a custom, virtual clone() function from the base class. Since the type of the object assigned from doesn't have to be the same, both copy construction and assignment would actually clone the object. The object is probably held using a std::unique_ptr<T> or a custom clone_ptr<T> which automatically takes care of appropriate cloning of the type.
3. The object is too big to be embedded. Of course, that case doesn't really happen unless you happen to implement the large object and create a suitable handle for it.

In most cases I would actually implement the assignment operator in an identical form, though:

T& T::operator=(T other) {
    this->swap(other);
    return *this;
}

That is, for the actual copy of the assigned object the code would leverage the already written copy constructor and destructor (both are actually likely to be = default ed) plus a swap() method which just exchanges resources between two objects (assuming equal allocators; if you need to take case of non-equal allocators things get more fun). The advantage of implementing the code like this is that the assignment is strong exception safe.

Getting back to your approach to the assignment: in no case would I first delete an object and then allocate the replace. Also, I would start off with doing all the operations which may fail, putting them into place at an appropriate place:

C& C::operator=(C const& c) { std::unique_ptr tmp(new B(*cb)); this->a = ca; this->b = tmp.reset(this->b); return *this; }

Note that this code does not do a self-assignment check. I claim that any assignment operator which actually only works for self-assignment by explicitly guarding against is not exception-safe, at least, it isn't strongly exception safe. Making the case for the basic guarantee is harder but in most cases I have seen the assignment wasn't basic exception safe and your code in the question is no exception: if the allocation throws, this->b contains a stale pointer which can't be told from another pointer (it would, at the very least, need to be set to nullptr after the delete b; and before the allocation).

  b->operator=(*(c.b));
  (*b).operator=(*(c.b));

These two operations are equivalent and should be spelled

  *this->b = *c.b;

or

  *b = *c.b;

I prefer the qualified version, eg, because it works even if b is a base class of template inheriting from a templatized base, but I know that most people don't like it. Using operator=() fails if the type of the object happens to be a built-in type. However, a plain assignment of a heap allocated object doesn't make any sense because the object should be allocated on the heap if that actually does the right thing.

Answer 3

If you use method 1 your assignment operator doesn't even provide the basic (exception) guarantee so that's out for sure.

Best is of course to compose by value. Then you don't even have to write your own copy assignment operator and let the compiler do it for you!

Next best, since it appears you will always have a valid b pointer, is to assign into the existing object: *b = *cb;

Answer 4

a = c.a;
*b = *c.b;

Of course, if there is a possibility that b will be a null pointer the code should check that before doing the assignment on the second line.