Copy Constructors
-
Can someone give me a quick explanation on copy constructors and what they are used for? I am alittel confused about them. Thanks!!
The copy constructor is called instatements like this:
CFoo a;
CFoo b(a); // this calls actually: b.CFoo(a);There are many such occasions, some more hidden (e.g. passing a CFoo as argument or return value of a function) if you don't provide your own, C++ generates a default copy constructor, which does a "memberwise copy", i.e. the copy constructor is called for each member. "Simple" types (non-classes/structs) are copied bitwise.
Flirt harder, I'm a coder.
mlog || Agile Programming | doxygen -
Can someone give me a quick explanation on copy constructors and what they are used for? I am alittel confused about them. Thanks!!
A copy ctor is used to instantiate an object of a class with a copy of another object of that same class. i.e. If I wanted a
CPointthat had the same values as anotherCPoint(say, one I wouldn't want to modify), then I would do the following:foo(const CPoint& pt)
{
CPoint MyPoint(pt);
...
}Thus you need to implement a ctor with the following prototype:
CMyClass(const CMyClass&)
And then set all the necessary class internals needed to represent a copy. ~Nitron.
ññòòïðïðB A
start -
The copy constructor is called instatements like this:
CFoo a;
CFoo b(a); // this calls actually: b.CFoo(a);There are many such occasions, some more hidden (e.g. passing a CFoo as argument or return value of a function) if you don't provide your own, C++ generates a default copy constructor, which does a "memberwise copy", i.e. the copy constructor is called for each member. "Simple" types (non-classes/structs) are copied bitwise.
Flirt harder, I'm a coder.
mlog || Agile Programming | doxygen -
Is it a good idea to always put a copy constructor in your class? Even if you are not gonna do a copy like: CFoo a; CFoo b(a);
yes+no When designing the class, which behavior the class should expose on copy. So you might need: a) the default copy constructor (i.e. add don't add your own) b) your own copy-constructor, if the default one makes something wrong/unwanted c) a protected or private "do-nothing" copy constructor, if th class isn't copyable
Flirt harder, I'm a coder.
mlog || Agile Programming | doxygen -
Is it a good idea to always put a copy constructor in your class? Even if you are not gonna do a copy like: CFoo a; CFoo b(a);
"Always" is such a strong word. As the previous reply said, if you don't define one, one is created for you. It's important for you to define one if the default behavior won't work for you. The perfect example of this is if your class includes a pointer to an object on the heap: class CFoo { ... CBar* m_pBar; }; The default copy constructor will just copy the pointer, so you'll end up with two CFoo objects pointing to the same CBar object on the heap. This can result in ugly crashes if the destructor includes deleting the CBar object. So, in this case you will want to define your own copy constructor that will make a copy of the CBar object. There's one more theory on all this. If you have a really large class with a lot of member variables and items on the heap you won't necessarily want the user of your class to be able to copy it as this will lead to poor performance. So, instead in the private section of your class declaration, declare your Copy constructor but never define it: CFoo { ... CFoo(const CFoo&); }; Thus, anytime you or another future programmer accidentally calls the copy constructor on your huge class the compiler will disallow it. So, the short answer, no it's not always a good idea.