Memory Leak

[aladden]

Here is the situation:

class B {
int b;
// no virtual ~B declare here
};

class D : public B {
int d[1000000];
};

B* pb = new C;
....
delete pb;

Do I leak memory since I don't declare a virtual destructor in B
class? Thanks in advance

 

[Victor Bazarov]

Here is the situation:

class B {
int b;
// no virtual ~B declare here
};

class D : public B {
int d[1000000];
};

B* pb = new C;

You mean

B* pb = new D;

...
delete pb;

Do I leak memory since I don't declare a virtual destructor in B
class? Thanks in advance

Maybe. Your code has *undefined behaviour*. Anything may happen.

V

 

[Andrey Tarasevich]

Here is the situation:

class B {
int b;
// no virtual ~B declare here
};

class D : public B {
int d[1000000];
};

B* pb = new C;
...
delete pb;

Do I leak memory since I don't declare a virtual destructor in B
class? Thanks in advance

You invoke undefined behavior. There's no way to say what will happen.
Maybe the memory will leak, maybe your computer will crash, maybe
something else.

Trying to perform a polymorphic deletion of a non-polymorphic class has
nothing to do with any "memory leaks". The often mentioned prediction
that it will cause "memory leak" is a rather ignorant urban legend.

 

[Thomas J. Gritzan]

Why would destroying an object of derived type using a base type
pointer, in the case where this base type has no virtual destructor,
result in a memory leak and memory corruption (assuming, like was the
case here, that the derived class only has an array as member)?

For the same reason that using delete instead of delete[] could cause a
memory leak: The pointer is not adjusted correctly prior passing it to
the deallocator. Also, the sub-objects of the derived class cannot free
its memory, because their destructors aren't called.

Formally it's UB, practically you should avoid it and shouldn't care
about what can go wrong.

 

[vcbaby]

Because that's the most common practical result of undefined behavior.


Well, just giving one random situation: if the subclass allocated something
from the heap, since its destructor won't get called, it won't deallocate
the memory, resulting in a leak.

Duh.

 application_pgp-signature_part
< 1KViewDownload

there's no memory leak after the code snippet in the top post is
executed, since
code in two classes don't allocate any memory(actually, no code in
both class)
and memory block pointed by pb is freed by 'delete pb'.

the memory used by an object itself and the memory allocated by the
object aren't the same thing
operation delete will call destructor and free memory used by object
itself.
the destructor free memory allocated by the object.

 

[Sirius Black]

That's one possibility, but formally, the behavior is undefined.


In general, it's pointless to speculate about what might be the cause
of various things when code has undefined behavior. One reason for
making it undefined is that there are may things that can go wrong.

For example, usually the destructor frees the memory. The destructor
knows the object's type and how large it is; there's nothing
prohibiting taking advantage of that knowledge. Further, if the
underlying memory manager is malloc/free, it won't work right if the
address of the base sub-object is different from the address of the
actual type.

Will this be possible in any case other than when multiple inheritance is used?

~ Sirius