Is memory allocated on stack or on heap?

[ayatsynych]

Hi,
Is there any way to determine at run-time if block of memory allocated on stack or on heap? For example:

BYTE* pData = new BYTE[100];
BYTE data[100];
BYTE* pData1 = &data[0];

//Hot to determine that pData is on heap, and pData1 is 
//on stack?

UPDATE: As I understand there is no generic solution for this one, so I need solution for Windows platform. I know that there is _CrtIsValidHeap Pointer (debug version only). Is there other ways how to do it?


Thank you!

[Banfa]

You should not rely on being able to tell how a piece of memory is allocated. If it matters then you should create a way to pass that information round your system, however it would be better to design the system so that you do not need to have to know this by either always allocating on the heap or always allocating on the stack.

[ayatsynych]

Thanks Banfa,
Sure, it's not something that should be used in the system design, I was just curious, because recently saw C++ implementation of DataBuffer (something like this one: DataBuffer), and creators were trying to detect if attached block of memory is on heap or on stack, so they would know how to handle this memory further.
Anyhow, thank you very much for answering my question!

[Banfa]

A DataBuffer class should manage the buffer memory itself. Since it should allocate the memory it knows how to deallocate it.

[ayatsynych]

Yep, it it has functionality to attach existing data store, it mean that memory was already allocated before, and you don't know if you can do realloc on this memory, or not

[Banfa]

Well for strict safety the memory buffer should allocate its own buffer and copy the data passed to it into its own buffer. The buffer passed should remain owned by the caller and be unchanged.

However there are times when you want to avoid that sort of copying, for example in an application that is solely responsible for transmitting data from a source to a destination repeatedly copying buffers can result in a serious reduction in through-put.

However a DataBuffer class should never be allowed to take ownership of a stack buffer because it can't properly do that. The ownership remains with the function that has the buffer on its stack because it will deallocate the buffer when the function exits.

What the class could have though to prevent multiple copying is a method to transfer ownership of a buffer allocated on the heap to it, you might call it something like takeOwnershipOf HeapBuffer to make it clear that once called the class has ownership and that it should only be called for a buffer allocated from the heap.

But the need for something like this should be determined by there being an actual need for it rather than by assuming it is required because of the risk of incorrect calling it introduces. That is, if possible, the DataBuffer class should be built using copying, then once the application is running if the performance is low the application should be profiled and then if then problem is with the DataBuffer classes copying something should be done to reduce the amount of copying done.

You should build your classes for safety and then only compromise that safety if the application is not meeting its performance criteria.

[ayatsynych]

Banfa, thank you very much!
Great answer!