managed c++

[mickey]

Hi, I read this below of managed c++ and I has introduced objects on the stack? Does anyone know why (or wich advantages ) this? I think on the stack the manage of object should be more quick, but how many objects can take on it? I think not so many....What do you think, please?

value class classB {
private:
	int value;
 
};
classeB^ bHeap = gcnew classeB(); //on managed heap
classeB bStack;  //on managed stack

value class classB {
private:
	int value;

};
classeB^ bHeap = gcnew classeB(); //on managed heap
classeB bStack;  //on managed stack

To copy to clipboard, switch view to plain text mode 

[wysota]

On modern computers it doesn't really matter. Allocation on stack is a bit faster. And stack size is practically limited only with the amount of virtual memory.

BTW. What is a managed stack? Is there anything to manage there?

[mickey]

And stack size is practically limited only with the amount of virtual memory.

What do you want to say? ( I dont' understand the sense)

BTW. What is a managed stack? Is there anything to manage there?

I now on the stack is managed from some actions of OS...But I thought in that case, CLR take some action even on the stack (or to permit the object goes on the stack)
Then what's the reasons to permit objects on the stack instead of heap (more larger). Aren't the objects on the stack more dangeroues? thanks

[wysota]

What do you want to say? ( I dont' understand the sense)

That if the situation allows you to allocate either on stack or on heap, you can do as you want. Usually you allocate small amounts of memory on stack and big amounts of memory on heap. But if you need a big chunk of memory only within a single scope, you can allocate it on stack as well as it's not likely that you'll run out of stack (which used to be a real threat "in the old days").

Aren't the objects on the stack more dangeroues? thanks

Dangerous? How come?

[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