Archived

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

Psycho_68

size of int* ??

Recommended Posts

I got bored so i made this program that clears up system memmory, it works realy well and clers 224MB out of my 256. It creates a lot of int* on the heap/free store. The only problem is that an int* should be 4 bytes but the program seems to be eating up memmory a lot faster, about 8 times faster, weird, heres the code:
#include <iostream.h>

int main()
{
	int* stand = 0;
	
	int i = 0;
	int megcount = 0;

	while(1)
	{
		stand = new int;
		i++;
		if(i==(256*1024)
		{
			i=0;
			megcount++;

			cout << megcount << "\n";
			cout << flush;
		}
		if(stand==0)
		{
			cout << "cleared " << megcount << " MB of memmory ;)\n";
			return 0;
		}
	}

	return 0;
}
anybody know why/what did i do wrong? [edited by - Psycho_68 on July 28, 2003 4:51:34 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
didn''t look at your code, but be aware that there''s a certain overhead in allocating data as the heap manager keeps track of the size of each allocated block. Also, when you allocate many small blocks like this, your memory will be fragmented and it''s unlikely that you can allocate as much as you wish. When allocating an int, it''s also possible that you will get more than just 4 bytes, your only guarantee is that it''s *at least* sizeof(int) bytes, but you could get more.

Share this post


Link to post
Share on other sites
holy shit

that is the biggest abomination of a program i've ever seen

edit: you realize thats basically a 224 meg memory leak? and done 4 bytes at a time? not only do you leak all your memory, you fragment it to hell, if you weren't using a modern os that cleans up after your process...

[edited by - billybob on July 28, 2003 5:49:42 AM]

Share this post


Link to post
Share on other sites
heh my initial plan for the program was to crash the system

yes its a memmory leak, but when the program stops, I get my memmory back

i have win 98 and ive run the program about 10 times 2 hours ago and my system hasnt crashed yet

Q: is there some way how not to fragment it?

Share this post


Link to post
Share on other sites
oh in that case, ist not so bad
allocate in 1 k-meg blocks, (stand = new int[1024] for a kilobyte)

saying 224/256 allocated isn''t exactly accurate, since the os might have swapped your memory/some other program''s memory to make room for it.

you should make it so it allocates in 1 meg blocks until new returns null, then 1 k blocks until new returns null, then 512 maybe, or 256, reduce the size again, until one byte at a time.

Share this post


Link to post
Share on other sites
quote:
Original post by mputters
quote:
Original post by billybob
(stand = new int[1024] for a kilobyte)



Ehm an int is rarely one byte

Heh, of course. same idea though, can''t believe I said that, I''m getting retardeder.

Share this post


Link to post
Share on other sites
quote:
Original post by billybob
that is the biggest abomination of a program i''ve ever seen

edit: you realize thats basically a 224 meg memory leak?
The iostream.h was more of an abomination.

Share this post


Link to post
Share on other sites
iostream.h is no longer part of the standard, iostream is what you should use. most standard libraries have iostream.h simply as using std::blah, where blah is the iostream related classes.

Share this post


Link to post
Share on other sites
quote:
Original post by Psycho_68
a int is 4bytes


Not necessarily. For the most part, yes, but the standard only defines the size of an int as being bigger or equal to a short, and smaller or equal to a long.

Share this post


Link to post
Share on other sites
Just out of curiosity Psycho, are you programming in C++ .NET? 'cause I don't understand how you get your memory back without delete, unless you're using .NET (which I've heard takes care of such things, but don't know for myself)


Oh, and so you know, yes, the OS will "swap" other app's memory to the HDD, but it will swap it back if it's needed and there's free space, so if it gets swapped to the HDD and isn't swapped back, wouldn't that mean he's freed up that much RAM space? If you got TweakXP (I forget what it's name was before XP) it has a "free RAM" button that basically does exactly what this prog does--except deletes the fluff objects when it's successfully filled your memory as far as it can..

[edited by - Erzengeldeslichtes on July 30, 2003 3:06:08 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Erzengeldeslichtes
Just out of curiosity Psycho, are you programming in C++ .NET? ''cause I don''t understand how you get your memory back without delete, unless you''re using .NET (which I''ve heard takes care of such things, but don''t know for myself)



The OS reclaims the memory when the program ends.

Share this post


Link to post
Share on other sites
Then why is it that such a thing as a "memory leak" exists and is a cause for major concern among us game programmers and almost every game in existance has at least one patch with the phrase "fixed memory leak in..." in it if the OS automatically reclaims memory?

Share this post


Link to post
Share on other sites
In reply to Erzengeldeslichtes''s statement:
Then why is it that such a thing as a "memory leak" exists and is a cause for major concern among us game programmers and almost every game in existance has at least one patch with the phrase "fixed memory leak in..." in it if the OS automatically reclaims memory?

I quote the AP:
quote:
Original post by Anonymous Poster
The OS reclaims the memory when the program ends.


Read the last word.

Share this post


Link to post
Share on other sites
yep.. the concern isnt about rebooting all the time, but about having to restart the game. just think about that last ultima game with its long list (i think closing and restarting every hour was pretty common). sounded like "to avoid mem leaks dont change armor, dont change weapons, dont read the journal, dont do anything, dont play the game in the first place". which made me wonder if those guys ever thought about free/delete during development to have mem leaks virtually everywhere. but i guess thats if you get if your lead programmer is calles "Captain Kangaroo" in the credits.

Share this post


Link to post
Share on other sites
1. The size of the int* will always be the size of a pointer. You can get the size (in bytes) of this by doing:

sizeof(int*)

or

sizeof(VARNAME)

to get a size of an int, do sizeof(int)

If your memory is comming back you must be using managed C++ - because any other way it simply wouldn''t. Each time you are doing a new, you are creating a dynamic instance of something in the memory. The int* simply points to that bit of memory you just allocated

Then you overwrite that pointer to the bit of memory you just created, thus nothing knows where it is anymore and it still is allocated. You may be lucky and the OS might be keeping tabs on your memory - but that is far far from certain.

The only way to deallocate the memory with a new is a mirroring delete on the same pointer.

Personally I use an adaption of a popular prefix notation, where p = pointer, m_ is a class instance member variable, m_i would be a class instance member int variable and so on. That makes things more readable.

The only reason I can think of you would write a program to purposely do this is to screw up someones machine. How about doing something more constructive huh?

Share this post


Link to post
Share on other sites
Knowing the limits of your system can be quite constructive. That's why you're allowed to sell books on hacking, because they're there so you know how the hackers do it and you can design your systems to prevent it.

I've done tests to see what can and can't be done. It's quite useful. In the case of what Psyco did, it's useful for finding out if your compiler or OS is managed, etc. Hopefully I never find a command by the name of CreateMagicProcessorSmoke(); when I'm testing...

[edited by - Erzengeldeslichtes on July 30, 2003 5:06:59 AM]

Share this post


Link to post
Share on other sites