Click to See Complete Forum and Search --> : life span of dynamicaly allocated memory


mikledet
December 12th, 2002, 09:14 AM
Hi Guys,

Cinsider the code:
class MyClass { /*stuff*/};

void foo()
{
MyCalss variable;
Myclass *pointer = new MyClass;

/* do stuff */

}

Which of the following is correct:
1.At the end of the function scope, both, variable and pointer will be destryed, that includes automatic destructor call for pointer, and all memory use by both variable and pointer will be returned to the system

2.At the end of the function scope, Only variables memmory is returned to the system, while only the pointer it self is destroyed but the allocated memory stays, untill delete will be called for it explicitly.

I think 2 is correct - can any one second that?

If its true, it actualy means, that dynamic allocation is in fact static - since the momory stayes "reserved" untill explicit delete call.
I use to think all "things" that are not declared as "static" should be dedstryed on end of scope - including the memory they used...

Thanks for any replies.

All the best

Dani.

dude_1967
December 12th, 2002, 09:43 AM
Dani,

This issue can often be a source of confusion. At the end of the function foo, "variable" will go out of scope and its destructor will be called. However, for the variable "pointer" it is a bit more confusing. The variable will go out of scope and it can no longer be used. But the destructor of the class will not be called and the memory reserved by the call to new will not be released.

This forces you to consider several things in your design. The programmer is responsible for the cleanup of pointers allocated in this fashion. There is a use of pointers called, I think, "smart pointers" which deal with this problem. Some other competent person should explain the theory behind smart pointers.

There is also an advantage to allocation and non-cleanup: New pointer elements can be added to lists in subroutines and manipulated beyond the scope of the subroutines. This can be very powerful for many design elements.

Chris.

:)

mikledet
December 12th, 2002, 09:59 AM
Hay Chris,

Yap, so basicaly you secod waht i thought too, as you said - it can be confusing (the pointer part)...

Thanks for your reply

All the best

Dani.

TheCPUWizard
December 12th, 2002, 10:50 AM
It is not so confusing if you think about it this way

new = creates memory and returns a method of accessing that memory (pointer). This memory must be somehow deleted or there will be a leak. If the created item is an object, the constructor will be called.

delete = released memory that has been allocated by new. Requires a method to identify the memory (pointer returned by new). If the item is an object, the desctructor will be called.


"raw pointers" = "SOMETHING *ptr". This hold a reference to some memory, which may have been created by new. This is called raw because it does nothing with the memory unless you write the code.

"smart pointers" = some class that takes a reference to memory and supports build in operations for that memory.

"auto ptr" = a smart pointer with a destructor that automatically deletes the memory.

"com_ptr" = a smart pointer that decrements the reference count on a com object [reference going to zero will delete the object typically!].

It is important to note that there are times where you do NOT want to explicitly delete the memory created by new. In fact there are (rare) occasions where it is totally illegal to use the pointer returned by new!!:D Also it is always an error to delete memory that was NOT created by new.


Hope this clears some things up.

mikledet
December 12th, 2002, 01:32 PM
Wizard,

Thanks for the input!!
I have only one question:
Also it is always an error to delete memory that was NOT created by new.
Why? I mean, delete will call free() down the line - and i have seen this statment many times...(that one should not mix delete alloc - free new)
Could you explain a bit?

All though, i never mix them up, plain out of "neatness"...

Thanks

Dani

TheCPUWizard
December 12th, 2002, 01:46 PM
Easily...

int f()
{
CMyClass x;
CMyClass *y = &x;
delete y;
}


the delete call will call the destructor for instance x, then try to return the memory to the HEAP, however it came from the stack. This is often an immediate crash.

If that does not kill the program, the existing of function f() will call the destructor on instance x as it goes out of scope, but the object has already been destroyed.

As far as mixing new/delete and alloc/free, there is no guarantee that the two methods will use the same memory area, this can result in the same problem as above. Also alloc/free will not (typically) call constructors/destructors.

mikledet
December 12th, 2002, 02:04 PM
Hi,

Ummm...
I easely get the c++ diferance - meaning - the call to destuctors...(delete) (should of thought of that my self:rolleyes:)
But, I dont get the heap stack explantion...
I mean, in C you can also allocate from heap or from stack - and all though i don't KNOW, my gues is - that free() will return to stack - so you can free dynamicaly allocated memory... the staticaly allocated will die any way on end of scope...
May be if you add to your exmple a free() call?


Thanks for your time man!

All the best

Dani

TheCPUWizard
December 12th, 2002, 02:19 PM
All local variables [lets not confuse him with static locals] get allocated on the stack when the function enters, the stack is restored to its initial condition of function exit.

All variables created with new [ lets not confuse him with placement new, of overloading the new operator] get created on the heap.

Most compilers use the same heap for new/delete as they do for alloc/free, but they often allocate the memory in subtly different ways.

Gabriel Fleseriu
December 12th, 2002, 03:07 PM
Originally posted by mikledet
Why? I mean, delete will call free() down the line - and i have seen this statment many times...(that one should not mix delete alloc - free new)
Could you explain a bit?

Of course, what Wizard said about dtors is absolute correct. I just wanted to drop a piece of info, for the sake of completeness: although many implementations of new/delete use malloc/free in their guts, there is no place in the Standard that sais that this has to be so. The Standard only states that new is allowed to be implemented in terms of malloc, but malloc is not allowed to be implemented in terms of new.

TheCPUWizard
December 12th, 2002, 03:19 PM
Gabriel, thank you for stating more clearly wht I had burried in my earlier post...

As far as mixing new/delete and alloc/free, there is no guarantee that the two methods will use the same memory area, this can result in the same problem as above

Saurabh Gupta
December 17th, 2002, 03:00 AM
Actually new is doing three work.
1. creating raw memory.
2. type casting
3. call the constructor.

If you are creating a memory using malloc, that memory should be raw memory and it does not call
constructor of that class.

And memory allocation mechanism should be different in new and alloc.

And in every process block have different type memory block. Like some read only, stack and heap.
All the function local variable are declared in to stack. And you have any pointer of stack variable, which would be pointed to garbage after pop of stack. So heap is consistent area for memory allocation. It destroys only explicitly. So, when you call Delete, OS would be de-allocated it and marked as unused in the memory page, So , it could be used further.

mikledet
December 17th, 2002, 05:04 AM
Just to say thanks guys for all your input - I HAVE read it all - and i think a i know one bit more then i did before - thanks!.
Oh and:
[lets not confuse him with static locals][ lets not confuse him with placement new, of overloading the new operator]
Oh please DO! :D

galathaea
December 17th, 2002, 12:22 PM
To add to TheCPUWizard and Gabriel's earlier distinction between new and malloc, it is common practice to refer to the space of memory where "new" objects get created as the free store, so as not to confuse it with malloc's heap. Even though they are often the same memory, the free store and the heap are independent in the standard.