about memory deallocation

Hi!

The memory manager will deallocate the number of bytes you have reserved. It doesn''t know the type of the pointer you pass to it, only look the address and the number of bytes reserved for that address.



"If you''''re gonna die, die with your boots on"

for most 32bit machines this particular example is probably moot as sizeof(int) == sizeof(long)

However, i''m not so sure the memory manager will do the ''right thing'' in a more risky example

eg short vs. long

this is certainly disastrous if you''re talking about pointers to classes - unless you did a dynamic_cast to a more derived pointer type and the base class has a virtual destructor.

quote:

---

Original post by SteveC
However, i''m not so sure the memory manager will do the ''right thing'' in a more risky example

---

Memory managers have been doing the ''right thing'' for years.

Take the following example:

long *foo = new foo[10]; short *bar = foo; ... delete[] bar;

So, what happens when bar is freed? How does delete know that bar contains 10 members? It doesn''t.

If foo was deleted instead, it still wouldn''t know it had to delete 10 members because the size of the array is not part of foo ''s type.

Instead, the implementation must keep a track of what memory has been allocated, and how big each requested chunk was. When it comes to deleting it, it merely has to look at the information that new has collated to know how much to delete.

quote:

---

this is certainly disastrous if you''re talking about pointers to classes - unless you did a dynamic_cast to a more derived pointer type and the base class has a virtual destructor.

---

The reason you want to worry about classes derived from classes with non-virtual destructors has nothing to do with freeing the derived class itself, but to do with freeing memory allocated by the derived class''s constructor: if you use delete on a pointer of the base class''s type, the derived class''s dtor won''t be called and you''ll end up with a memory leak.

Just Plain Wrong

Good point Mayrel

but that is just because we are talking about built in types.

the raw memory will be removed because it looks up some table for pointer and slot size -

at the lowest level of memory alloc/dealloc

however, as you alluded to - delete also calls destructors on each object to be delete ( hence the need for the array form )

so delete [] bar must know to call it a number of times based upon the number of array elements

maybe doing a sizeof alloc/sizeof(type) kind of thing

in which case if we were talking about objects as opposed to pointers to objects then bad things would happen as the number of destructor calls would be incorrect and may scribble

that''s above and beyond the issue of wrong destructor calls and other potential memory leaks

at any rate it at least seems like very bad practice to call delete on a type after a C-style cast to a different type

like i said, i wouldn''t be surprised if certain implementations check this in debug mode

?