Archived

This topic is now archived and is closed to further replies.

Enokh

new and delete to save memory space?

Recommended Posts

int *TempInt = new int; *TempInt = CountAnims(TempInt); for (int i = 1 ; i <= *TempInt ; i++) { Animation *TempAnim = new Animation; TempAnim->ReadData(); Animlist.insertEnd(*TempAnim); } delete TempInt; The code up there gets a new int up and running, performs a function on that int, and then uses that int in a FOR loop, so that the loop only happens TempInt times. Then it deletes the int because I no longer need it in the program, ever. Correct me if I''m wrong, but isn''t that more efficient than just doing int x; performing the function on x, and never deleting it? Is this type of logic/programming efficient, is it considered ''good''?

Share this post


Link to post
Share on other sites
I think the point you''re missing is that if you declare a variable within a function just using ''int x;'' (not new delete etc.), then at the end of that function the compiler will delete the variable for you, since it has gone out of scope. The same applies if you declare say ''int i'' in the first parameter of a for loop, the variable only exists for the duration of the loop. There''s nothing wrong with this style of programming in general.

You really start to see the benefit of the new and delete operators when you''re working with large blocks of memory, and complex pointer operations, however.

Share this post


Link to post
Share on other sites
TempInt [int *TempInt] is a 32bit var!
So you are using a 32 bit pointer to allocate another 32 bit type(int)... you are using 64 bits!
[[
just think...
after
delete TempInt;
you can use it again:
TempInt = new int[100]
]]
And you forgot to delete the TempAnim!
{
Animation *TempAnim = new Animation;
TempAnim->ReadData();
Animlist.insertEnd(*TempAnim);
delete TempAnim;
}
You are adding the data "*TempAnim" and you overwrite the TempAnim (the pointer) each time, you can not delete it later.



[edited by - Kambiz on October 11, 2003 3:23:29 PM]

Share this post


Link to post
Share on other sites
quote:
Is this type of logic/programming efficient, is it considered ''good''?


I think that the example you provided is not suitable to illustrate the best use for pointers. Pointers are, to mention just an example, good to use when loading all the info for one level of your game. Instead of declaring an array variable like this:

CEnemy Enemies[100];

you declare it like this:

CEnemy *lpEnemiesList;

and then you determine at run-time how many CEnemy´s you´d like to declare:

lpEnemiestList = new CEnemy[iNumberOfEnemies]; // Assumes iNumberOfEnemies holds the correct value.

I hope my explanation has been useful.

--Ignacio Liverotti
iliverotti@hotmail.com

Share this post


Link to post
Share on other sites
Ok a few things, that bit of my code is in my Winmain function, and not a local-style function, so that int will only be deleted when the program ends (could be 30 mins from the start of it) as opposed to when THAT bit of code ends (a few milliseconds from the start of the app).

"TempInt [int *TempInt] is a 32bit var!
So you are using a 32 bit pointer to allocate another 32 bit type(int)... you are using 64 bits!
"

But when I delete the int, it deletes the pointer too? So for a moement there I'll be using 64 bits, and then 0 from when I delete the int and onwards, as opposed to using 32 bits the entire length of the program.

As for the actual code inside the FOR loop, it's a list which will be completely destroyed when the app ends, so there's no point in deleting TempAnim because it'll be destroyed later anyway. (And actually if I destroy it in that bit of code, outside of the loop then the last animation will not work, and inside the loop, none of the animations will work, I'm sure you can see why).


On that specific occasion I'm only saving an int, sure, but what I'm really asking is if this principle is good on a general level. To further clarify, or to properly define said principle, basically it says that you have time-based variables, that only exist for as long as you need them to. So that int will only exist in memory for a few milliseconds, and that memory will be able to used by other variables as the program continues. The normal option would be to declare int AnimCount; and work with that instead, but that seems rather wasteful to me, as AnimCount will only be worked with for a few lines of code for the ENTIRE scope of the app, as that int is declared essentially globally. What do you guys think?

[edited by - Enokh on October 11, 2003 3:38:07 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
int *x = new int; does not take up 64 bits, but assigns an allocated address to that pointer and the the amount is stored int the pointer.
the difference between int *x = new int; delete x; and int x is that without new the variable is pushed on the stack, while new places it on the free store,with a limited amount of stack space that can''t always be a good thing esp if you have alot of large classes;

Share this post


Link to post
Share on other sites
quote:
Original post by Enokh
On that specific occasion I''m only saving an int, sure, but what I''m really asking is if this principle is good on a general level. To further clarify, or to properly define said principle, basically it says that you have time-based variables, that only exist for as long as you need them to. So that int will only exist in memory for a few milliseconds, and that memory will be able to used by other variables as the program continues. The normal option would be to declare int AnimCount; and work with that instead, but that seems rather wasteful to me, as AnimCount will only be worked with for a few lines of code for the ENTIRE scope of the app, as that int is declared essentially globally. What do you guys think?


The solution there is to use a scope. Like this:

void somefunc()
{
blah();
{
int i; // ''i'' is created here

blah();
} // at this point, ''i'' no longer takes up any space

blah();
}



How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
quote:
But when I delete the int, it deletes the pointer too? So for a moement there I'll be using 64 bits, and then 0 from when I delete the int and onwards, as opposed to using 32 bits the entire length of the program.


No the pointer will stay there till the end of winmain so what you get is you have a 4-byte pointer you allocate 4-btyes and so you have 8-bytes you delete the int and you now have 4-bytes that hangs around till the end of winmain.

Of course this is a rather simplified way of looking at things. It's not a good idea to allocate ints on their own you may as well use a local variable. This is because local variables are allocated on what is known as the stack, while memory allocations are done on what is known as the heap. For reasons I won't get into you can allocate small values such as 4-byte ints on the stack extremely quickly. While on the heap even you allocate a 4-byte int it will actually use up a relatively large chunk it depends on the OS to what this size will be but it may be something like 1024 bytes (I may actually be wrong on this point but I think I'm correct). Heap allocations and deallocations also take far longer than on the stack.

Only allocate memory for large structures. Use local variables (or if you have to global variables) for small things like ints.

[edited by - Monder on October 11, 2003 3:44:21 PM]

Share this post


Link to post
Share on other sites
quote:
Correct me if I''m wrong, but isn''t that more efficient than just doing int x; performing the function on x, and never deleting it? Is this type of logic/programming efficient,

This is 99% of the time the wrong question to ask. Whenver someone asks these type questions I will almost always respond with a bold PREMATURE OPTIMIZATION SUCKS. Don''t waste time on completely insignificant speedups like these. Especially when you are learning. Throw out any notions of "what''s faster" until you are absolutely certain that you need it. (Hint: merely writing a game is NOT carte blanche need for this sort of thing).

quote:
is it considered ''good''?

Better question to ask. Not really, because there are more things that you as the programmer must remember to do.

(Oh, and allocating an int by saying int i uses the stack, which is going to be several orders of magnitude faster than using objects on the heap.)

When I teach programming, I will explicitly avoid any mention of speed or performance until the time is right. Instead I will try to teach them that elegant, simple and understandable code segments are far more important than raw performance.

Share this post


Link to post
Share on other sites
So you guys are saying to put that bit of code in a function and use int x; instead of having that code in the WinMain open up like that and using new/delete. Makes sense, and it's even simpler ;-)

Thanks!

[edited by - Enokh on October 11, 2003 4:00:42 PM]

Share this post


Link to post
Share on other sites
Your original code will actually use more ram and cost execution time. In order to get an int using new, you have to have a pointer which is usually a unsigned long int (32 bits on x86, 64 bits on sparcs) that will stay around while that function is in use. So that is 4 or 8 bytes always in that function. Secondly, they system may have to make a kernel call to ask for more ram. This will take time and usually will end up with the kernel giving you at least a KB of ram which new will then subpartition for you of what you want. For just a single int this is not worth it. If it was an array or you were making a lot of different ints this would be worth it since the memory manager (yes C and C++ do have a memory manager... just not a garbage collector) can reuse the space it already has and doesn''t have to ask the kernel for more.

What I am saying is that it depends on your usage. Dynamically allocation larger arrays can be of use for helping your program run in a smaller memory footprint by getting rid of ram that you don''t need. However, if you are using a single variable at a time, you gain nothing from dynamic memory and at the same time actually lose speed and efficency of memory.

BTW, I wouldn''t worry about efficency right off the bat. Better to have a correct program then a super efficent one. Of course if you can code effiecency in your program without having to think then go for it, but remember correct programs are better then efficent programs.

Share this post


Link to post
Share on other sites