Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / February 2007

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
mclp - 21 Feb 2007 12:05 GMT
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 - 21 Feb 2007 14:36 GMT
> CString& mfcstr;
> String^ str = gcnew String(mfcstr);
[quoted text clipped - 6 lines]
> 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.

> Thanks,
> M
mclp - 22 Feb 2007 09:46 GMT
Ben, many thanks for your input.

Strange... I sent a much longer reply yesterday but it never appeared.
Ben Voigt - 22 Feb 2007 16:21 GMT
> 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).

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.