Is this a mem leak?
The moral of the story is: don''t come here for programming advice. Buy a good book instead, Stroustrup''s in this case.
quote:Original post by gumby
The moral of the story is: don''t come here for programming advice. Buy a good book instead, Stroustrup''s in this case.
YUO == TEH WIN!!1 =D
quote:Original post by Agentidd
EDIT*****************************
#include <iostream>
using std::cout;
using std::endl;
int main()
{
int* eger[40000];
for (int count = 0; count < 50000; count++)
{
eger[count] = new int;
cout << "int " << count << endl;
}
delete *eger;
return 0;
}
After running this source code, i was basically looking for it to crash. I''m playing around a little seeing what can be done and what can''t.
I ran this code, expecting a crash when it tried to assign eger[40000] or 40001. Well.. no error. It actually kept assigning values up to 40031.
Why in the world would it go to 40031 and then stop.? Why didn''t it stop earlier. Can anyone explain this anomolie to me?
If ya don''t believe me try it. I'',m using Visual 6.0 Standard.
EDIT*****************************************
Go back to college...
j/kThe reason is that you are writing past the array''s last element (one reason for using iterators and a vector in this case.) The compiler doesn''t check for this (though I think VS.NET has a compiler option to do so at runtime.) This is a classic mistake frequently made with arrays.
Depending on your compiler and whether you compiled in debug or release this bug could actually be really hard to find.
Lastly, your call to delete is wrong:
delete *eger; should be:
delete [] eger; Hope this helps.
HEY !
int *pint=new int;
is NOT A LEAK
but if you forget it, then its A LEAK
This question is extremely silly. Please learn thy basics and post again.
Thanks
Signed BY
THY M. C.
int *pint=new int;
is NOT A LEAK
but if you forget it, then its A LEAK
This question is extremely silly. Please learn thy basics and post again.
Thanks
Signed BY
THY M. C.
Run windows explorer 20 times in a row under win98 and you''ll run out of free memory and have to reboot.
So win98''s explorer was poorly coded and has memory leaks?? Or just the OS itself?
Some of my programs were doing the same thing under windows 98.
I do as above
int* pint=new int;
but I ALWAYS use a delete with anything "new" how hard is it to just delete it before exiting? come on now..
So win98''s explorer was poorly coded and has memory leaks?? Or just the OS itself?
Some of my programs were doing the same thing under windows 98.
I do as above
int* pint=new int;
but I ALWAYS use a delete with anything "new" how hard is it to just delete it before exiting? come on now..
quote:Original post by thy MC
HEY !
int *pint=new int;
is NOT A LEAK
but if you forget it, then its A LEAK
This question is extremely silly. Please learn thy basics and post again.
Thanks
Signed BY
THY M. C.
The question was not whether this single line:
int* pint = new int;
is a memory leak. The question was is this:
int main() {
int* pint = new int;
}
a memory leak. The answer is yes.
Regards,
Jeff
quote:Anonymous Poster
So you''re saying that even after the function has finished, and he activation frame is removed from the stack, it''s not a leak because the address is still somewhere on the stack? Come on.
It''s not, that doesn''t matter. A leak is when you lose track of memory, not when you don''t free it - a consequence of leaking is that memory (and perhaps other resources) are not freed.
quote:Xai sorry magmai, this time your wrong, because when the function exits, the only remaining pointer to the memory is lost ... so it''s a classic leak ...
Perhaps a classic [technically incorrect] example. It is like leak, but it is not one. Your program must lose the pointer to leak, not freeing resources is not the definition of leaking.
quote:
another reason to think of this as a memory leak is because all software which helps detects memory leaks will call this a leak ... which means leaving junk like this in the program will prevent you from finding the real / important leaks deeper in your code (i assume you are asking if it is a leak to intentionally not call delete on an object since you know the OS will reclaim the space) ...
You guys had me worried enough to check, but I am not wrong. It is technically a memory-pool. The pointer is held for the entire life-time of the program. If the pointer had been allocated in a function other than main it c/would be a leak.
void crap() { int* i = new int; //leak static int* i2 = new int; //pool //note that i2 is only constructed once, // no matter how many times ''crap'' is invoked'' } - Magmai Kai Holmlor
"No, his mind is not for rent to any god nor government" - Rush, Tom Sawyer
[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]
[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]
[Free C Libraries | zlib ]
quote:Original post by Ready4DisOriginal post by Agentidd
I just finished my college course in C++ … and I could have remebr being told that memory gets freed when it gets out of scope.
Say I have an integer declared in a function.
int getajob(blahblah)
{
int crap = jommastrash;
return crap;
}
-DD
Yes, but that''s a single variable. We''re talking about allocating memory using new. That memory for that variable is actually allocated within the executable, so even though it goes out of scope, the memory doesn''t get deleted until the executable is unloaded
. actualy I think you''re wrong. The local variable is allocated on the stack. Therefore, when the function exits, the stack pointer is returned to the position it was before the call to the function, therefore, your variable is lilkely to be not valid anymore. Therefore, never return a reference to a local variable, because that reference will be pointing forward in the stack, which would likely to be overwritten shortly after you exit the function.
int& getajob(blahblah)
{
int crap = jommastrash;
return crap;
}
is wrong.
int getajob(blahblah)
{
const int crap = 3;
return crap;
}
here, I''m not entirely sure, but my guess is ''crap'' would not even physcally exists, and the compiler would probably replace it straight by 3 at compilation, like a #define.
int& getajob(blahblah)
{
static int crap = 3;
return crap;
}
here, ''crap'' resides on the main memory, and is automatically freed by the program when the program exits. So it is safe to return by reference or value.
however
static int* pVal=0;
void main(void)
{
pVal = new int;
*pVal = 3;
}
is wrong again. You''ve got to free it before the program exits. Anyway, as a rule of thumb, always call delete for a new, and delete[] for a new[]. Delete[] will call the destructor on each elements of the array, as well as free the array. delete after a new[] would only free the array, without calling the destructor for the elements. Well, that''s what I''ve been told, but it''s generaly a bad idea.
you can use stand-alone libraries such as memwatch, to track down memory leaks. search for it on google.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement