Simple C++ Curiosity: Using 'free()' with 'new'?
Author
Is there danger to using 'free()' to deallocate space that was allocated using 'new' in C++? Especially in arrays?
It seems as though in my program, there is a memory leak, and every half a minute or so, the program's memory will increase by around 4 KB when using my font class. I am sure that I am allocating/deallocating properly using the 'new[]' and 'delete[]' operators (with a global variable).
I know it may seem somewhat odd, but 4,096 bytes of 'leaky' space allocation per minute doesn't seem like a lot, but it does concern me in the long run...
Yes, you definitly do not want to mix free with new and delete with malloc. I don't have any bookmarked links or articles as to why, but you will be getting a lot of replies not to mix the two.
Calling free() on a pointer you got from new or new[] will probably not call the destructors, which in turn may cause leaks as resources are not freed, may corrupt the heap, especially if multiple allocators are involved, and has been shown to cause cancer in lab rats.
Author
THanks for the clarification on that.
But are there any articles explaining the inner workings of 'new[]' and 'delete[]'? And are there any that cover those operators when dealing with polymorphism?
...
Poor little lab rats. [sad]
But are there any articles explaining the inner workings of 'new[]' and 'delete[]'? And are there any that cover those operators when dealing with polymorphism?
...
Poor little lab rats. [sad]
Not really; how they work is implementation-defined.
For array new and delete (i.e. new[] and delete[]), polymorphism is irrelevant; objects in an array must have the exact type of the array storage, which follows from the necessity of knowing the size of each array element and of those sizes being equal (so that indexing can be done by simple pointer arithmetic), and from the fact that a derived class could add members. Thus anything you put into the array is "sliced" into a base class ([google] "C++ object slicing").
For single-item new and delete, the size of the allocated memory might be tracked in the same way as it is for new[] and delete[], or it might be tracked in a different way, or if the class is non-polymorphic, it might not be tracked at all, as an optimization (since the size of the thing is known at compile time, the deallocation can just return that many bytes to the freestore). (That optimization generally isn't available for new[] and delete[] because the *number* of elements isn't generally known at compile time.)
And of course, new/new[]/delete/delete[] call ctors and dtors; free and malloc do not. free and malloc also aren't even required to use the same memory pool; they use "the heap" in standard-talk while the others use "the freestore", and they could be entirely unrelated. While the easiest conceptual explanation of new might be in terms of a call to free() and a static function that contains the ctor code, there are no guarantees about how the compiler actually does it - just about the net effect.
More info here. But basically, you *must* use free for malloc, delete for new, and delete[] for new[]; and no other combinations are ever valid. As a good design principle, never design with the intent that a pointer might point at either a new'd thingy or a new[]'d one. It's rare enough that you might think it's a good idea; it never actually is. ;) Instead, have it always point at an array, and allocate an array of size 1 when needed. (EDIT: Better yet, use std::vector, or something else along those lines.)
For array new and delete (i.e. new[] and delete[]), polymorphism is irrelevant; objects in an array must have the exact type of the array storage, which follows from the necessity of knowing the size of each array element and of those sizes being equal (so that indexing can be done by simple pointer arithmetic), and from the fact that a derived class could add members. Thus anything you put into the array is "sliced" into a base class ([google] "C++ object slicing").
For single-item new and delete, the size of the allocated memory might be tracked in the same way as it is for new[] and delete[], or it might be tracked in a different way, or if the class is non-polymorphic, it might not be tracked at all, as an optimization (since the size of the thing is known at compile time, the deallocation can just return that many bytes to the freestore). (That optimization generally isn't available for new[] and delete[] because the *number* of elements isn't generally known at compile time.)
And of course, new/new[]/delete/delete[] call ctors and dtors; free and malloc do not. free and malloc also aren't even required to use the same memory pool; they use "the heap" in standard-talk while the others use "the freestore", and they could be entirely unrelated. While the easiest conceptual explanation of new might be in terms of a call to free() and a static function that contains the ctor code, there are no guarantees about how the compiler actually does it - just about the net effect.
More info here. But basically, you *must* use free for malloc, delete for new, and delete[] for new[]; and no other combinations are ever valid. As a good design principle, never design with the intent that a pointer might point at either a new'd thingy or a new[]'d one. It's rare enough that you might think it's a good idea; it never actually is. ;) Instead, have it always point at an array, and allocate an array of size 1 when needed. (EDIT: Better yet, use std::vector, or something else along those lines.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
