cannot delete array of pointers...

[Zoulz]

Hello, i've encountered a strange little thing. I pass a pointer by reference to a function in a DLL. The function creates a dynamic array from the pointer by using new. That works fine, the data in the array is filled like it should. But, when I try to delete the array from the main program, delete throws a runtime error. :/ any clues?

Function from my DLL:

void DDraw::Get_Enumeration_Result(Enum_Result *&result, int &resultCount)
{
	int	idx = 0, sz = (int)deviceEnum.size();

	result = new Enum_Result[sz];
	resultCount = sz;

	for(enumIterator = deviceEnum.begin(); enumIterator != deviceEnum.end(); ++enumIterator)
	{
		Enum_Result		tmp = (Enum_Result)*enumIterator;

		result[idx].enumWidth = tmp.enumWidth;
		result[idx].enumHeight = tmp.enumHeight;
		result[idx].enumDepth = tmp.enumDepth;
		idx++;
	}
}

Code in my main program:

	Enum_Result	*res = NULL;
	int			count;

	gfx->Get_Enumeration_Result(res, count);
	for(int i = 0; i < count; i++)
	{
		char txt[100];
		sprintf(txt, "%dx%dx%d", res[i].enumWidth, res[i].enumHeight, res[i].enumDepth);
		MessageBox(hWnd, txt, "Enum", MB_OK);
	}
	delete[] res;

[cvogt61457]

What's the error?

Debug build or Release Build?

[Zoulz]

Nevermind, it sorted itself out. It seems you cannot deallocate memory in a DLL from another program, so I had to create a release function in the DLL.

[wayside]

Originally posted by Zoulz
It seems you cannot deallocate memory in a DLL from another program, so I had to create a release function in the DLL.

Can someone explain why this is so?

I understand that it is good practice, and all, but I don't understand why it doesn't work.

[Paul McKenzie]

Originally posted by wayside
Can someone explain why this is so?

I understand that it is good practice, and all, but I don't understand why it doesn't work.

It will work provided that the client program uses the very same heap and functions used by the DLL. When "new" is called, it just doesn't "get memory" -- it has to adjust various data structures (the heap manager) to track the allocation. If the heap manager used by the DLL is different than the heap manager used by your application, the call to "delete" in the application will yield undefined results (most of the time, crashes).

In real-world scenario, what if I coded a regular DLL using Borland C++ Builder, and you use it in your Visual C++ application? The heap manager used by Builder is totally different than the heap manager used by Visual C++, therefore calling "delete" in your VC++ app on a pointer allocated with "new" created by the Borland runtime will leave disastrous results. As a matter of fact, If the DLL is coded in Visual C++, and it uses a specialized heap manager that I created -- your delete call will also yield disastrous results since the delete will assume that the heap manager used is the stock VC++ heap manager, when this is not the case.

This is why it's good practice to have one module control allocation and deallocation. The client program should not assume where the memory comes from or how it was allocated unless it is well documented (for example, memory obtained via GlobalAlloc can be freed by any module calling GlobalFree).

Regards,

Paul McKenzie

[wayside]

Originally posted by Paul McKenzie
It will work provided that the client program uses the very same heap and functions used by the DLL.

This is what I thought. In the case of the OP, it seems that he is building both the exe and the dll, so I would have assumed things would be in alignment. Bad assumption I guess.

In real-world scenario, what if I coded a regular DLL using Borland C++ Builder, and you use it in your Visual C++ application?

This would be like matter and anti-matter mixing, and half the world would be destroyed in the subsequent explosion.

[Paul McKenzie]

Originally posted by wayside
This would be like matter and anti-matter mixing, and half the world would be destroyed in the subsequent explosion.

Many DLL's that VC++ programmers use are not built with VC++. Some are built with other compilers, others are built with other languages, i.e. Delphi. You won't know it, since all you usually get is a LIB file (which can be created from an existing DLL), or you use LoadLibrary() to load the DLL.

So right now, you may be using a third-party DLL that was created with who-knows-what language or compiler.

Regards,

Paul McKenzie