gcroot use and clean up?

  • Thread starter Thread starter Maxwell
  • Start date Start date
M

Maxwell

Hello,

Im using MC++ VS.NET 2003 and am quite confused with with gcroot
template and its use. The issue I am confused about is the need to (or
not) delete a pointer to a managed object that you have created using
gcroot. For example(from Managed VC++ 2003 Step by Step by Microsoft
Press p510):

class UnmanagedClass
{
public:
gcroot<ManagedClass *>pMc;

UnmanagedClass(ManagedClass *)
{
pMc = in;
}

~ UnmanagedClass()
{
// do you need this????
delete pMc; //this was NOT in the microsoft sample
}
}



In MS documetion I get the impression that you would not have to
explicitly call delete like the code above because they didn't in thier
example and stated "When the unmanaged object goes out of scope, the
gcroot is destroyed, which frees the GCHandle and in turn frees up the
managed object". So by reading that I would infer (perhaps incorrectly)
one does not have to explicitly call delete . Can anyone confirm if
this a correct?

However, when I read the other posts in this newsgroup I get the
distinct impression that one should definitely call delete
explicitly...Is this a VS 2003 vs 2005 thing, I do see references in
this newsgroup that in c++/CLI there is this auto_gcroot templete which
I cannot find in VS 2003?

Also one other question I have if you use gcroot like above would one
have to "pin " the managed object before passing it into this unmanaged
constructor or is that the hole point of using gcroot?

Thanks
 
Hi Maxwell

Q1: Do you have to delete objects passed to gcroot?
A1: gcroot does not internally delete objects for you, so if your problem
domain requires the object to be deleted, you have to do it manually
In VC 2005, there is an msclr::auto_gcroot from the header
msclr/auto_gcroot.h for exactly that purpose

Q2: Is it necessary to pin objects before they are passed to gcroot?
A2: No. gcroot is a native type, but all its functions are managed
functions. Therefore you do not pass a gc objcect to native code

HTH

Marcus Heege
 
Marcus thanks much for the reply , the information helps alot. I dont
think I asked the question correctly for Q2... or did not supply all
the relevant info.

In the sample above, we have the class UmanagedClass:

///Unmanaged code
class UnmanagedClass
{
public:
gcroot<ManagedClass *>pMc;


UnmanagedClass(ManagedClass *in)
{
pMc = in;
}


~ UnmanagedClass()
{
// do you need this????
delete pMc; //this was NOT in the microsoft sample
}
}

On the mananged code side we have 2 objects ManagedClass and
ManagedCompositeClass. To create the unmanged object in the
ManagedCompositeClass I would have to supply a managed object something
like

//Managed code
__gc class ManagedClass
{
ManagedClass()
{
}
ManagedClass()
{
}
void doSomething()
{
Console::WriteLine("Hello world");
};
}

__gc class ManagedCompositeClass //Managed code
{
ManagedCompositeClass()
{
ManagedClass mClass = new ManagedClass();
UnmanageClass *pUc = new UnmanagedClass(mClass);
}
ManagedCompositeClass()
{
delete *pUc;
}

}

Since I am passing in a managed class to the UnmanagedClass would I
have to worry about garabage collection of the managed class or is that
what the gcroot is for in the unmanaged class?

For example should the code be like this instead in order to be safe:

__gc class ManagedClass //Managed code
{
ManagedCompositeClass()
{
ManagedClass mClass = new ManagedClass();
ManagedClass __pin *pinnedMClass = mClass;
UnmanageClass *pUc = new UnmanagedClass(this);
}
ManagedCompositeClass()
{
pinnedMClass=0;
delete *pUc;
}

}

Now the code Aobve for the pinned stuff doesnt seeem to make sense to
me, but I wanted to make sure I didn't have to "Pin" a managed object
before passing it to a unmanaged object and its starts calling stuff on
that managed object.

I think Myabe I just dont understand when you pin and when you dont or
how gcroot falls in there....I see that gcroot allows you to use a
managed object in unmanaged code. That much I get, but when using that
managed object in the example I provided where you have to pass it in a
constructor of a unmanaged object, should you pin it first?
 
Back
Top