"new" and "delete"
Author
Greetings all, I was just reviewing my c++ looking at Teach Yourself C++ in 21 days by Sams and saw that sometimes in the book when memory was allocated with "new" that there was NOT always a corresponding "delete" call! Shouldn''t "new" and "delete" always be called in pairs? Look at chapter 12 for example:
============================
int main()
{
Mammal *pDog = new Dog;
Dog->Speak();
Dog->Move();
return 0;
}
===========================
The destructor does not free the memory either.
Thanks in advance.
-----------------------------
"There are ones that say they can and there are those who actually do."
"...u can not learn programming in a class, you have to learn it on your own."
Although the memory will be released when the program exits, it''s rather bad programming practice. Yes, new and delete should be called in pairs.
yes.... yes they should. Just another fine code example from the people at Sams 
It won''t be that much of a problem, since windows is going to keep track of your memory allocations anyway, and should get rid of everything at the end of the program. Should being the opperative word. However, if you want to be a good coder, you should always call delete or delete[] if you call new or new[].
also, when you get into DX coding, ALWAYS call Release() on COM objects that you query for, even if example code forgets.
It won''t be that much of a problem, since windows is going to keep track of your memory allocations anyway, and should get rid of everything at the end of the program. Should being the opperative word. However, if you want to be a good coder, you should always call delete or delete[] if you call new or new[].
also, when you get into DX coding, ALWAYS call Release() on COM objects that you query for, even if example code forgets.
and if you want to get really nitpicky about your memory management, you override new and delete to pull from a preallocated chunk of memory, a pre-defined array, or from a predefined linked-list.
if your loading and unloading objects on the fly, you dont want to be actually allocating and deallocating memory. you be so fragmented after only a couple loads and unloads that the game would freeze because you wouldnt have enough room to load anything thing anymore, which is totally unacceptable. if you didnt take this approach, the pointer clean up code necessary for such memory management would be an ugly mess thatd be slow, which may or may not be acceptable. this is speaking from a purely console development standpoint, im not too familiar with optimizing pc memory mangament...though, i pretty positive that it wouldnt be much different.
if your loading and unloading objects on the fly, you dont want to be actually allocating and deallocating memory. you be so fragmented after only a couple loads and unloads that the game would freeze because you wouldnt have enough room to load anything thing anymore, which is totally unacceptable. if you didnt take this approach, the pointer clean up code necessary for such memory management would be an ugly mess thatd be slow, which may or may not be acceptable. this is speaking from a purely console development standpoint, im not too familiar with optimizing pc memory mangament...though, i pretty positive that it wouldnt be much different.
Very rarely are you going to have to do that in PC development. Memory managment schemes of Win2k, Xp, and linux are good enough to the point where you''ll frequently take memory back you''ve deallocated with delete. Actually, other programs might take memory you''ve removed with delete . However, what you''re saying is probably good practice anyway. However, this is assuming that the person knows how much memory they want to take at the begining of their programming. On a console, you have a set ammount, and you can take it ALL. On PC, you just kinda take stuff
. However, what you''re saying is probably good practice anyway. However, this is assuming that the person knows how much memory they want to take at the begining of their programming. On a console, you have a set ammount, and you can take it ALL. On PC, you just kinda take stuff
quote:Original post by Anonymous Poster
and if you want to get really nitpicky about your memory management, you override new and delete to pull from a preallocated chunk of memory, a pre-defined array, or from a predefined linked-list.
if your loading and unloading objects on the fly, you dont want to be actually allocating and deallocating memory. you be so fragmented after only a couple loads and unloads that the game would freeze because you wouldnt have enough room to load anything thing anymore, which is totally unacceptable. if you didnt take this approach, the pointer clean up code necessary for such memory management would be an ugly mess thatd be slow, which may or may not be acceptable. this is speaking from a purely console development standpoint, im not too familiar with optimizing pc memory mangament...though, i pretty positive that it wouldnt be much different.
It's much different. Windows/Linux allocates memory to processes in pages, for one thing, so there's little fragmentation. (since you always get a whole page, and subsequent allocation comes from that page until you need a new one.) Fragmentation can happen within pages, but only during the course of a program run, since pages are released once you exit. On average, a given program will be 'fragmented' to about half of a page.
Even on OSes without virtual memory or paging, OSes tend to allocate extra memory at the start of a program execution, since the OS developers expected you to malloc or new some new memory right off the bat - so there's usually extra memory floating around already to expand into.
On the PC, Pre-allocating a linked list or an array is a useful performance enhancement when you're adding/removing elements on the fly, but it's faster because it reduces context switching and calls out to the OS, not because of any fragmentation concerns.
Edited by - cheesegrater on December 19, 2001 10:09:20 AM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
