Copy constructors and the = operator

A lot of the tutorial sites that I've seen have copy constructors and = operators that contain much the same code. My question, therefore, is the following valid?

Code:

---

SomeClass::SomeClass(const SomeClass &sc)
{
  *this = sc; // After all, we're copying sc, and what is copying but an assignment?
}

SomeClass::operator = (const SomeClass &sc)
{
  if(this == &sc) return *this;

  // Do copy, freeing current data items as needed.
  return *this;
}

---

This seems to be the easiest way to do a copy constructor, as are these two examples below not functionally equivalent:

Code:

---

// SomeClass scA has been previously defined / initialzed with data.
SomeClass scB(scA);
SomeClass scC = scA;
SomeClass scD;
scD = scA;
// Are not all those functionally equivalent?
// (Only differing between when the data is set to a value?)

---

Just wondering if what I'm writing is legal. I've used the above (calling operator = in the copy constructor) and never ran into any problems... just want to know if it's waiting to blow up in my face or not.
Thanks.

I am not entirely sure if such assignment to *this is valid, but from what I know you should do it the other way: implement the copy assignment operator in terms of the copy constructor, using a swap() member function.

Code:

---

SomeClass::SomeClass(const SomeClass &sc)
{
    // perform copy
}

SomeClass& SomeClass::operator = (const SomeClass &sc)
{
    if (this != &sc)
    {
        SomeClass temp(sc);
        swap(temp);
    }
    return *this;
}

---

The check for this != &sc may be unnecessary if swap() can handle swapping an object with itself, but then you might want to avoid copy construction if it is expensive.

Laserlight's way is best. Operator= usually duplicates the code for the copy constructor and destructor; using the method laserlight did, that's taken care of.

There's an even better reason to do it like this -- IF you make sure that swap() cannot throw an exception, then your code is exception-safe and has commit-or-rollback semantics; in the event of an exception in constructing temp, the object remains unchanged.

Using the assignment operator from within the copy-constructor causes problems when the assignment operator usually takes care of decllocating existing resources before assigning new ones. But if the internal members are not initialised yet, it might try destroying garbage.
Such assignment operator behaviour is usually the case in implementations of smart pointer.

Code:

---

SomeClass scC = scA;

---

FYI, such assignments are transformed by the compiler into:

Code:

---

SomeClass scC(scA);

---

Does that mean it's faster to do scC(scA) than scC = scA?

Quote:

---

Does that mean it's faster to do scC(scA) than scC = scA?

---

Probably, and copy construction should be no slower than copy assignment since for you to be able to assign, the object to assign to must have already been constructed.

Quote:

---

Originally Posted by iMalc

Using the assignment operator from within the copy-constructor causes problems when the assignment operator usually takes care of decllocating existing resources before assigning new ones.

---

That's actually a bad way to do things. Better is to create new, temporary resources, then when the resources have been allocated correctly, swap the temp and the object and let the destructor deallocate.

Else, if you deallocate an existing resource but have a thrown exception when trying to allocate the new one, your object is left with neither the old resource nor the new.

Quote:

---

Originally Posted by Cat

That's actually a bad way to do things. Better is to create new, temporary resources, then when the resources have been allocated correctly, swap the temp and the object and let the destructor deallocate.

Else, if you deallocate an existing resource but have a thrown exception when trying to allocate the new one, your object is left with neither the old resource nor the new.

---

Oh I know, I agree totally! I shouldn't have put the word "before" in there as it clouded the issue. Regardles of the order of allocation and deallocation of new and existing recourses, the existing resources are invalid/uninitialised, and calling the assignment operator in that case will fail.
My point is that any assignment operator that assumes the object is already constructed will fall over, if the object is not in fact already constructed, such as when you use it from the copy-constructor.