When we define the copy constructor, is it required that we clear the contents of the object we are writing over? I am implementing a binary search tree, and wondering if I wouldn't have a memory leak unless I clean it up when implementing the copy constructor and the assignment operator.
-
3Clear what? It hasn't been constructed yet, there isn't anything to clear. – Cory Kramer Jan 04 '16 at 19:29
-
1Unclear what you asking. Just ensure any allocation is paired with exactly one deallocation (new/delete, new[]/delete[], malloc/free, ...) – Jan 04 '16 at 19:29
-
If you are defining a copy constructor then there is nothing to clean as you are building from scratch. – Jean-Baptiste Yunès Jan 04 '16 at 19:29
-
What object you are writing over? Constructors are called on object creation. – Algirdas Preidžius Jan 04 '16 at 19:30
-
Are you confusing copy constructor with assingment operator? – SergeyA Jan 04 '16 at 19:36
3 Answers
When we define the copy constructor, is it required that we clear the contents of the object we are writing over?
At time of construction there's no content that needs to be overwritten. Just make sure you're doing all of the copies of member variables in the constructor member initializer list, rather than doing in the constructor's body.
Otherwise the compiler would generate default initialization for members, and then there could be something allocated, that actually needs to be cleared and overwritten (or deep copied).
Especially if you're dealing with pointers as you claim to do.
Best you should follow The Rule of Three (Five) to ensure everything is done consistently.
-
Upvoting for actually making sense of the seemingly senseless question by bringing members into the picture. – SergeyA Jan 04 '16 at 19:39
-
-
1@LightnessRacesinOrbit, how did you come into picture? And what happened to the red herring comment I was going to address? – SergeyA Jan 04 '16 at 19:41
-
@SergeyA: I came into the picture because you didn't want to also upvote my answer :( – Lightness Races in Orbit Jan 04 '16 at 19:42
-
-
@LightnessRacesinOrbit There are differences for implementations in the member initializer list vs copying in the constructors body? Don't see you mentioned that, neither the _red herrings_ so much? But have an upvote, so what :-P ... – πάντα ῥεῖ Jan 04 '16 at 19:45
-
@LightnessRacesinOrbit, I didn't expect someone with almost 200K rep to even think about reputation :) But I see no reason not to upvote it. – SergeyA Jan 04 '16 at 19:48
-
1
-
@SergeyA It's more about accepting _correctness_ ... I don't care about the rep so much. – πάντα ῥεῖ Jan 04 '16 at 19:50
-
@LightnessRacesinOrbit, πάντα ῥεῖ - OK. I am still not clear what is considered a good answer here (for example, I was often downvoted for answers which I believe to be similar to LRiOs with comments - *useless* or *this should be a comment*. – SergeyA Jan 04 '16 at 19:53
-
-
@LightnessRacesinOrbit _"People are silly"_ I've been prooving this soo many times ;-) ... – πάντα ῥεῖ Jan 04 '16 at 20:09
If a copy constructor is running, there is no "object we are writing over". You are creating ("constructing") a new object, from scratch, but copying data from some other object to populate its initial state.
For an assignment operator, yes this is definitely a consideration and you need to be sure to avoid leaks. Though, if you employ RAII so you don't have any manual memory management, then you have nothing to worry about. (Beyond that, I don't understand how pointers come into it.)

- 378,754
- 76
- 643
- 1,055
As the others have stated, using the copy constructor will create a new object.
What you have to consider, tho:
If your original object is the owner of some other data e.g. foo*
allocated with new
or a shared_ptr
, copying the object will simply copy the pointer and its adress.
You will not actually copy the owned data.
In case of a raw foo*
and a delete foo
in your destructor, the second object being destroyed will try to delete removed memory.

- 433
- 3
- 10