views:

212

answers:

7

If the operator= is properly defined, is it OK to use the following as copy constructor?

MyClass::MyClass(MyClass const &_copy)
{
    *this = _copy;
}
+15  A: 

If all members of MyClass have a default constructor, yes.

Note that usually it is the other way around:

class MyClass
{
public:
    MyClass(MyClass const&);     // Implemented
    void swap(MyClass&) throw(); // Implemented
    MyClass& operator=(MyClass rhs) { rhs.swap(*this); return *this; }
};

We pass by value in operator= so that the copy constructor gets called. Note that everything is exception safe, since swap is guaranteed not to throw (you have to ensure this in your implementation).

EDIT, as requested, about the call-by-value stuff: The operator= could be written as

MyClass& MyClass::operator=(MyClass const& rhs)
{
    MyClass tmp(rhs);
    tmp.swap(*this);
    return *this;
}

C++ students are usually told to pass class instances by reference because the copy constructor gets called if they are passed by value. In our case, we have to copy rhs anyway, so passing by value is fine.

Thus, the operator= (first version, call by value) reads:

  • Make a copy of rhs (via the copy constructor, automatically called)
  • Swap its contents with *this
  • Return *this and let rhs (which contains the old value) be destroyed at method exit.

Now, we have an extra bonus with this call-by-value. If the object being passed to operator= (or any function which gets its arguments by value) is a temporary object, the compiler can (and usually does) make no copy at all. This is called copy elision.

Therefore, if rhs is temporary, no copy is made. We are left with:

  • Swap this and rhs contents
  • Destroy rhs

So passing by value is in this case more efficient than passing by reference.

Alexandre C.
Actually, it doesn't matter if MyClass has a default constructor. Only if data members and base classes have one...
Cătălin Pitiș
yep you're right.
Alexandre C.
Ok, thanks. I was doing this to avoid code duplication in the implementation of the `operator=` and the copy constructor. With the copy-and-swap idiom the code is duplicated in the copy constructor and the `swap` method. Am I right?
gregseth
@gregseth: not quite. The swap operation usually does "shallow" swap, for instance, by swapping just pointers (when appliable). The copy semantic is usually "deep" and thus quite different from the swap semantic. You don't have the code duplication which arises usually with copy ctor/operator= since operator= is implemented *in terms of* the copy ctor.
Alexandre C.
+4  A: 

This implementation implies that the default constructors for all the data members (and base classes) are available and accessible from MyClass, because they will be called first, before making the assignment. Even in this case, having this extra call for the constructors might be expensive (depending on the content of the class).

I would still stick to separate implementation of the copy constructor through initialization list, even if it means writing more code.

Another thing: This implementation might have side effects (e.g. if you have dynamically allocated members).

Cătălin Pitiș
A: 

I would say this is not okay if MyClass allocates memory or is mutable.

duffymo
If it's not mutable, then it won't have an `operator=` -- that's a mutating function. Or do I not mean the same thing by mutable as you do?
Steve Jessop
+5  A: 

It is more advisable to implement operator= in terms of an exception safe copy constructor. See Example 4. in this from Herb Sutter for an explanation of the technique and why it's a good idea.

http://www.gotw.ca/gotw/059.htm

Steve Townsend
+1  A: 

While the end result is the same, the members are first default initialized, only copied after that.

With 'expensive' members, you better copy-construct with an initializer list.

struct C {
   ExpensiveType member;

   C( const C& other ): member(other.member) {}
};



 };
xtofl
You can't initialize outside construction.
GMan
@GMan: darn. I meant to write the copy constructor, not the assignment. Sorry for that.
xtofl
No problem, removed -1. :)
GMan
A: 

yes.

personally, if your class doesn't have pointers though I'd not overload the equal operator or write the copy constructor and let the compiler do it for you; it will implement a shallow copy and you'll know for sure that all member data is copied, whereas if you overload the = op; and then add a data member and then forget to update the overload you'll have a problem.

queBurro
A: 

@Alexandre - I am not sure about passing by value in assignment operator. What is the advantage you will get by calling copy constructor there? Is this going to fasten the assignment operator?

P.S. I don't know how to write comments. Or may be I am not allowed to write comments.

Manoj R
Okay, I edit my answer to provide more details.
Alexandre C.
The usual reference is http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/. I'm still not convinced it's conclusions are always correct.
Steve Jessop
@Steve: For `operator=`, since you have to do the copy anyway, it cannot be worse.
Alexandre C.
@Alexandre C: yes it can. For example, if the function isn't inlined then it might result in more copies of the (call to) the copy constructor, bigger binaries, more cache misses, slower. The article mentions this, it isn't hiding anything, and I'm not convinced that it *never* matters whether the caller or the callee does a particular bit of work, on all compilers, ever.
Steve Jessop