Question

I am extremely confused about resource management in C++/CLI. I thought I had a handle (no pun intended) on it, but I stumbled across the auto_gcroot<T> class while looking through header files, which led to a google search, then the better part of day reading documentation, and now confusion. So I figured I’d turn to the community.

My questions concern the difference between auto_handle/stack semantics, and auto_gcroot/gcroot.

1. auto_handle: My understanding is that this will clean up a managed object created in a managed function. My confusion is that isn’t the garbage collector supposed to do that for us? Wasn’t that the whole point of managed code? To be more specific:

   //Everything that follows is managed code
   void WillThisLeak(void)
   {
       String ^str = gcnew String ^();
       //Did I just leak memory? Or will GC clean this up? what if an exception is thrown?
   }
   
   void NotGoingToLeak(void)
   {
       String ^str = gcnew String^();
       delete str;
       //Guaranteed not to leak, but is this necessary? 
   }
   
   void AlsoNotGoingToLeak(void)
   {
       auto_handle<String ^> str = gcnew String^();
       //Also Guaranteed not to leak, but is this necessary? 
   }
   
   void DidntEvenKnowICouldDoThisUntilToday(void)
   {
       String str();
       //Also Guaranteed not to leak, but is this necessary? 
   }
   

   Now this would make sense to me if it was a replacement for the C# using keyword, and it was only recommended for use with resource-intensive types like Bitmap, but this isnt mentioned anywhere in the docs so im afraid ive been leaking memory this whole time now

2. auto_gcroot

Can I pass it as an argument to a native function? What will happen on copy?

    void function(void)
    {
        auto_gcroot<Bitmap ^> bmp = //load bitmap from somewhere
        manipulateBmp(bmp);
        pictureBox.Image = bmp;  //Is my Bitmap now disposed of by auto_gcroot?
    }

    #pragma unmanaged

    void maipulateBmp(auto_gcroot<Bitmap ^> bmp)
    {
        //Do stuff to bmp
        //destructor for bmp is now called right? does this call dispose?
    }

Would this have worked if I’d used a gcroot instead?

Furthermore, what is the advantage to having auto_handle and auto_gcroot? It seems like they do similar things.

I must be misunderstanding something for this to make so little sense, so a good explanation would be great. Also any guidance regarding the proper use of these types, places where I can go to learn this stuff, and any more good practices/places I can find them would be greatly appreciated.

thanks a lot,
Max

Answer 1

1. Remember delete called on managed object is akin to calling Dispose in C#. So you are right, that auto_handle lets you do what you would do with the using statement in C#. It ensures that delete gets called at the end of the scope. So, no, you’re not leaking managed memory if you don’t use auto_handle (the garbage collector takes care of that), you are just failing to call Dispose. there is no need for using auto_handle if the types your dealing with do not implement IDisposable.

2. gcroot is used when you want to hold on to a managed type inside a native class. You can’t just declare a manged type directly in a native type using the hat ^ symbol. You must use a gcroot. This is a “garbage collected root”. So, while the gcroot (a native object) lives, the garbage collector cannot collect this object. When the gcroot is destroyed, it lets go of the reference, and the garbage collector is free to collect the object (assuming it has no other references). You declare a free-standing gcroot in a method like you’ve done above–just use the hat ^ syntax whenever you can.

So when would you use auto_gcroot? It would be used when you need to hold on to a manged type inside a native class AND that managed type happens to implement IDisposable. On destruction of the auto_gcroot, it will do 2 things: call delete on the managed type (think of this as a Dispose call–no memory is freed) and free the reference (so the type can be garbage collected).

Hope it helps!

Some references:

http://msdn.microsoft.com/en-us/library/aa730837(v=vs.80).aspx

http://msdn.microsoft.com/en-us/library/481fa11f(v=vs.80).aspx

http://www.codeproject.com/Articles/14520/C-CLI-Library-classes-for-interop-scenarios