I created a neat little function to delete an ienumerable and it’s contents (to plug a memory leak I recently discovered):
generic<typename T>
void CollectionHelpers::DeleteEnumerable(IEnumerable<T>^% enumerable)
{
if(enumerable != nullptr)
{
for each( T obj in enumerable)
{
delete obj;
}
delete enumerable;
enumerable = nullptr;
}
}
…but for some reason, when I trace through with a debugger, the list still appears to point to some memory when I return from the DeleteEnumerable function.
I thought that by passing in as a tracking reference it should modify the handle I’m passing in? What have I missed here?
Edit: A more thorough test example…
This is a slightly updated disposer:
using namespace GenericCollections;
using namespace System::Collections::Generic;
using namespace System;
generic<typename T>
void CollectionHelpers::DeleteEnumerable(IEnumerable<T>^% enumerable)
{
if(enumerable != nullptr)
{
for each( T obj in enumerable )
{
Console::WriteLine("Disposing of object");
delete obj;
}
Console::WriteLine("Disposing of enumerable");
delete enumerable;
enumerable = nullptr;
}
if( enumerable == nullptr )
{
Console::WriteLine("enumerable tracking reference is nullptr");
}
else
{
Console::WriteLine("enumerable tracking reference is NOT nullptr");
}
}
This is a cut down example of the code which calls the disposer:
using namespace System;
using namespace GenericCollections;
using namespace System::Collections::Generic;
ref class MyClass
{
private:
int* m_myBuf;
public:
MyClass()
{
m_myBuf = new int[100];
Console::WriteLine("MyClass::MyClass()");
}
~MyClass()
{
delete [] m_myBuf;
m_myBuf = NULL;
Console::WriteLine("MyClass::~MyClass()");
}
};
int main(array<System::String ^> ^args)
{
List<MyClass^>^ myList = gcnew List<MyClass^>;
myList->Add(gcnew MyClass());
myList->Add(gcnew MyClass());
myList->Add(gcnew MyClass());
CollectionHelpers::DeleteEnumerable(myList);
if(myList == nullptr)
{
Console::WriteLine("Original list is disposed of");
}
else
{
Console::WriteLine(String::Format("Original list still referenced: {0}", myList));
}
return 0;
}
…and this is the output:
MyClass::MyClass()
MyClass::MyClass()
MyClass::MyClass()
Disposing of object
MyClass::~MyClass()
Disposing of object
MyClass::~MyClass()
Disposing of object
MyClass::~MyClass()
Disposing of enumerable
enumerable tracking reference is nullptr
Original list still referenced: System.Collections.Generic.List`1[MyClass]
To be honest, I’m not so worried whether deleting the enumerable works it’s the objects which are contained inside which needed to be killed off. We use these lists all over the place and our system was running out of memory because they weren’t being cleaned up quickly enough.
Worse still, we were relying on the DeleteEnumerable function to set our list tracking references to nullptr, but when they’re passed back out the tracking reference doesn’t appear to have been updated. It’s not just a debugger issue either as you can see from the console output.
What I don’t understand is why the
Okay, this behavior is indeed weird. And this is what actually happens:
You have a local variable of type
List<MyClass^>^and you are calling a method with a parameter of typeIEnumerable<T>^%. This is a problem. The method could set its parameter, say, toarray<T>^. In C#, code like this would not be allowed, but for some reason, it is allowed in C++/CLI. And it compiles down to something like:Do you see the problem? If you set the reference to
nullptrinDeleteEnumerable(), the local variableenumerablechanges, but notmyList.To verify, change your code to this:
And it correctly prints “Original list is disposed of”.
If you want to know why does C++/CLI behave in this way, maybe it’s so that tracking references behave similarly to normal C++ references?