managed c++

[mickey]

Dangerous? How come?

I think one reason of managed heap was have code more secure (from programming error). I I still have in mind that "managed stack", thinking that there is a runtime that take some action on the stack..
Then what's the reasons to permit objects on the stack instead of heap? (is it useful and when? I don't see any reason to have obj on the stack [apart a bit speed])--

[wysota]

I think one reason of managed heap was have code more secure (from programming error).

But from what kind of errors? What is so error prone with allocating data on stack?

Then what's the reasons to permit objects on the stack instead of heap? (is it useful and when? I don't see any reason to have obj on the stack [apart a bit speed])--

Stack allocated objects will automatically be destroyed when they go out of scope. That makes it easier to use them compared to heap allocated objects and it prevents memory fragmentation.

[mickey]

then, I'm just wondering wich kind of object is convenient to allocate on the stack instead of the heap? Or there is no difference and .Net has introduced objecst on the stack only to do something more?
Furthermore: what could happen if I write a c++ managed program and I send every objects on the stack?

[wysota]

Don't try to look for differences where there are none. The difference between stack allocated objects and heap allocated objects is the area of memory (hence pointer address) they are located in and automatic deallocation of stack based objects. Nothing more really.

[mickey]

sorry, but if an object goes on the stack, the runtime should perform less action at run time (maybe nothing operations). Is it so?

[wysota]

The only difference is that the memory is allocated in one go for the stack as a whole instead of each object separately, but in practice the operating system optimizes allocations by allocating a whole page as a pool and then serving the already allocated memory. Basically the allocation penalty can be ignored as long as you do anything else than just allocating and deallocating memory