Managed/Unmanaged Memory

[humble_learner]

Hi,

[Application]
The application consists of two physical parts - a .NET based GUI and a C++ based DLL.

[Functionality]

A. A user can provide details of a class (teachers name and students names) in the GUI and clicks on a button. The data is passed to the C++ DLL where it is written into a file.

B. A user can read the contents of a file and display on the GUI. In this case the C++ DLL reads the file contents and sends the data across to the UI.

In case A, memory is allocated by the Managed C# code and sent across to the C++ DLL (because the front end knows about the number of students on reading GUI entries)

In case B, the managed code sends across a 'ref' parameter to the C++ DLL. Memory is allocated in the C++ DLL and returned to the C# GUI for display (because the back end knows about the number of students on reading file)

I would like help to understand how best to design the interfaces between the GUI and the DLL so as to prevent memory leaks. Who has the responsibility of deleting allocated memory ?
Please let me know your views.

Thanks,
Humble Learner

[Talikag]

I don't know who has the responsibility of deleting allocated memory, but I can tell you that if you'll decide it's the C# program responsibility, you won't have to do much. C# has the Garbage Collector mechanism, which deallocate unnecessary data for you.
If you want to help the Garbage Collector recognize unnecessary data, all you have to do is to give the unnecessary data the value null:

Class myClass = new Class();
...
myClass = null;

[TheCPUWizard]

Change your design....

Only ONE portion should handle ALL memory allocation and associated management.

For example if the DLL reads a file and determines it needs space for 10 students, have a callback to the EXE which takes the number of students, creates the objects, and passes them back to the DLL for additional processing.

Mixing between environments is guraranteed to give you problems (maybe minor, maybe difficult, maybe fatal, but I do guarantee you will have them).

[nabeelisnabeel]

I liked the question.

[humble_learner]

Hi,

Thanks for the answer.
I do know of Windows APIs which require two calls - one to know the size so that buffer can be allocated (by the caller) and another to actually read the contents into the buffer allocated by the caller.

However, is calling the same function twice not a hit on performance - especially in an interop scenario where you are calling from managed to unmanaged code ?

Is there a solution where the memory allocated by the DLL can be released by the DLL during another explicit call (Uniitialize() for example) from the managed code to the DLL. (There could be the danger of the pointer being moved for some reason though)

I always thought that the "guy who knows allocates" - hence when the DLL knows it allocates and when the UI knows if allocates. But, I suppose this is a risky proposition in a managed/unmanaged scenario.

Please comment.