Destructor call at overwrite?

[Arne Claus]

Hi
I've got a little question about the following construct:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - -
class a {

public:
a() {
m_number =NULL;
}

~a() {
delete m_number;
}

setMember(int *myInt) {
m_number = myInt;
}

protected:

int* m_number;
};

// somwhere else in the code
a test;
a.setMember(new int(5));
test = a(); // memory leak?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - -

does this last line call a destructor on the original test, thus
destroying m_number correctly, or do I produce a memoryleak here? My
guess would be no, but I'm not entirely sure about that.

Arne

 

[Heinz Ozwirk]

class a {
public:
a() {
m_number =NULL; }
~a() {
delete m_number;
}
setMember(int *myInt) {
m_number = myInt;
}
protected:
int* m_number;
};

// somwhere else in the code
a test;
a.setMember(new int(5));
test = a(); // memory leak?

does this last line call a destructor on the original test, thus
destroying m_number correctly, or do I produce a memoryleak here? My guess
would be no, but I'm not entirely sure about that.

The last line of your code is an assignment. It does not call a destructor
before assignig the value. (It does call the destructor for the temporary
object created by a(), but that does not prevent a memory leak.

Remember the rule of three - whenever you need one of default constructor,
destructor or assignment operator, you most likely need the other two, too.

Also, programming in C++ (or or any other language) is not a guessing game.
You may call it a craft or an art or something between, put it is not a
place for guessing or gambling.

HTH
Heinz

 

[titancipher]

No, the destructor is not called. The compiler has generated a default
assignment operator and copy constructor for 'class a' that will do a
bit-copy only. The 'test = a()' assignment will over-write
test.m_number.

 

[comp.lang.c++]

Hi
I've got a little question about the following construct:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - -
class a {

public:
a() {
m_number =NULL;
}

~a() {
delete m_number;
}

setMember(int *myInt) {
m_number = myInt;
}

protected:

int* m_number;
};

// somwhere else in the code
a test;
a.setMember(new int(5));
test = a(); // memory leak?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - -

does this last line call a destructor on the original test, thus
destroying m_number correctly, or do I produce a memoryleak here? My
guess would be no, but I'm not entirely sure about that.

Arne

I guess that your correct test code is like this :

a test;
test.setMember(new int(5));
test = a();

The destructor is called on assigment and on exit.

If the test would be :
a* test = new a();
test.setMember(new int(5));
test.setMember(new int(5));// 1 leak
test = new a();//2 leaks
delete test;

This test code would've cause 3 memory leaks.

P.S The Debugger is your friend. Try to setup a breakpoint in the
destructor and see when is called.

 

[comp.lang.c++]

I guess that your correct test code is like this :

a test;
test.setMember(new int(5));
test = a();

The destructor is called on assigment and on exit.

If the test would be :
a* test = new a();
test.setMember(new int(5));
test.setMember(new int(5));// 1 leak
test = new a();//2 leaks
delete test;

This test code would've cause 3 memory leaks.

P.S The Debugger is your friend. Try to setup a breakpoint in the
destructor and see when is called.

Ignore this... The destructor call that I got was from the copy

 

[Ron Natalie]

No, the destructor is not called. The compiler has generated a default
assignment operator and copy constructor for 'class a' that will do a
bit-copy only. The 'test = a()' assignment will over-write
test.m_number.

Memberwise copy. I've never seen an implementation that copied bit by
bit. Usually it uses larger chunks

 

[Arne Claus]

No, the destructor is not called. The compiler has generated a default
assignment operator and copy constructor for 'class a' that will do a
bit-copy only. The 'test = a()' assignment will over-write
test.m_number.

So will overloading the operator = (and deleteing m_number there) do
the trick? Or do I have to create my own copy-constructor for this
case, too?

Arne

 

[Arne Claus]

Also, programming in C++ (or or any other language) is not a guessing

game. You may call it a craft or an art or something between, put it is
not a place for guessing or gambling.

Well I guess (^^) I know that, but as I don't have the Soustroup around
here asking before programming seems a lot better than just guessing,
programming and wondering where the hell those memory leaks come from,
doesn't it?

Arne

 

[Heinz Ozwirk]

So will overloading the operator = (and deleteing m_number there) do the
trick? Or do I have to create my own copy-constructor for this case, too?

Not for this special case, but whenever you have a non-trivial destructor
(for example one that delete's, you usually also need your own assignment
operator and copy-constructor. If you don't want to allow copying or
assigning to instances of such classes, you should at least declare them
private and don't implement them.

HTH
Heinz