Re: Managed/Unmanaged Memory
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:
Code:
Class myClass = new Class();
...
myClass = null;
Re: Managed/Unmanaged Memory
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).
Re: Managed/Unmanaged Memory
Re: Managed/Unmanaged Memory
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.