VC2005 C++/CLI VB.NET byref unmanaged interop

[mclp]

Hi. Just joined this group and I don't think this had been addressed
before..

I have a VB.NET class library assembly "xyz.dll" that I want to access
from some unmanaged code in an MFC DLL (contained in a cpp file
compiled with /clr) via:

#include <vcclr.h>
#using "xyz.dll"
using namespace System;
using namespace xyz;
...
gcroot<Moo^> boo = gcnew Moo;

My VB.NET assembly contains:

Public Class Moo
Public Sub Foo(ByRef s as String)
End Class

If I try to get to it using...

CString& mfcstr;
gcroot<String^> str = gcnew String(mfcstr);
boo->Foo(str);
mfcstr = str;

... the compiler complains that gcroot can't supply the reference
parameter (%).

However, if I just use:

CString& mfcstr;
String^ str = gcnew String(mfcstr);
boo->Foo(str);
mfcstr = str;

... then it works fine, but I'm concerned that by not using gcroot to
wrap the String^, that the String^ will not be garbage collected. The
working code does not result in a memory leak, but I'm not quite
satisfied with my understanding. Can anyone enlighten me as to what is
the correct way to handle my reference parameter.

Thanks,
M

 

[Ben Voigt]

CString& mfcstr;

String^ str = gcnew String(mfcstr);
boo->Foo(str);
mfcstr = str;

.. then it works fine, but I'm concerned that by not using gcroot to
wrap the String^, that the String^ will not be garbage collected. The
working code does not result in a memory leak, but I'm not quite
satisfied with my understanding. Can anyone enlighten me as to what is
the correct way to handle my reference parameter.

The latter way is correct.

gcroot has nothing to do with causing a ref class to be garbage collected,
rather quite the opposite, it prevents the object from being collected too
soon (and also updates whenever the object moves). Normally the garbage
collector searches for all references to an object before eliminating it,
including the managed heap and the stack (hence the latter way is correct,
with the reference on the stack the collector sees it). For a purely
managed program, that's enough. But using OS memory allocation primitives
(C malloc/free, C++ new/delete, Win32 HeapAlloc, VirtualAlloc, etc) you can
have memory that the collector isn't aware of. Then you need GCHandle,
which gcroot wraps conveniently for C++ programmers.

 

[mclp]

Ben, many thanks for your input.

Strange... I sent a much longer reply yesterday but it never appeared.

 

[Ben Voigt]

Ben, many thanks for your input.

Strange... I sent a much longer reply yesterday but it never appeared.

No worries. Hope that helped you.

The important thing with garbage collection is that you don't need to ensure
that stuff is freed exactly when the last user stops referencing it, you
just need to make sure the garbage collector knows what you're using,
because it already knows what other modules are using, and works on the
basis of reachability (so that cycles aren't such a problem as with
refcounts).